未来云计算会是什么样子

本文是一篇转载文

• 原文链接：未来云计算会是什么样子？Sealos 或将给出答案 ，
• 原文作者：魏鹏宇，来自哈尔滨工业大学，Sealos 社区贡献者，目前从事 Kubernetes 相关研发工作
• 作者博客：友链第三个

本文以时间顺序，结合历史与时代背景，介绍 Sealos 的发展历程与设计理念。并预测未来的发展。

1. 回首往事：操作系统与应用程序的发展

操作系统的产生与发展

从1945年第一台电子计算机出现开始，到 20 世纪50年代中期，并没有操作系统的概念，彼时计算机的工作方式是由操作员带着记录有程序和数据的卡片或打孔纸带去操作机器，装好卡片/纸带后，启动卡片/纸带阅读器，让计算机把程序和数据读入计算机机的内存中后，计算机就开始工作，并把结果也输出到卡片/纸带或显示屏上。

而由于人的操作与计算机处理不匹配，为了更好的发挥计算机的性能，出现了早期的批处理操作系统，它们可以更好的调用计算机的各项资源，以满足人们给出的不同任务。

随着计算机的发展，计算机所包含的硬件也越来越多，比如内存、cpu、硬盘等，而人们分配给计算机的任务也越来越动态而复杂，最终可以使用 ‘“应用程序” 来进行抽象。而这些应用程序与计算机各项设备之间的交互也越来越复杂，复杂到这些应用程序的开发者完全无法理解。

而计算机领域中，屏蔽复杂性最好的方法就是分层，没有之一。于是操作系统承担了在应用程序与计算机硬件之间充当中间层的工作，他们高效而安全的调度着计算机的各种资源给不同的应用程序使用，尽力发挥出他们的全部作用以满足应用程序的需要。

操作系统的基本功能

一台现代计算机的基本组成如下：

• CPU
• 内存
• 存储
• I/O 设备

而操作系统要调度这些资源，同时还要和应用程序进行交互，由此，我们可以分析出操作系统的基本组成：

• 进程管理：分配 CPU 资源
• 内存管理：分配内存资源
• 文件系统：分配存储资源
• 设备管理：分配 I/O 资源
• 应用程序接口：与应用程序进行交互

应用容器化

物理机资源隔离

1979年，为了实现资源的隔离，按照 UNIX “一切皆文件” 的设计理念，第七版 UNIX 操作系统中提供了 chroot 命令。该命令是 “change root” 的缩写，能是当某个进程经过 chroot 操作之后，它的根目录就会被锁定在命令参数所指定的位置，以后它或者它的子进程将不能再访问和操作该目录之外的其他文件。

2002年，Linux Kernel 2.4.19 引入了名为 “命名空间” 的隔离机制，在不同的命名空间中，不仅仅是文件，进程，用户，网络等等信息都实现了彻底的隔离。

但是一台物理计算机的资源毕竟是有限的，各种资源都不能无限制的增加，于是还需要做资源的隔离。

2008年，Linux Kernel 2.6.24 引入了 cgroups，用于限制某个进程组能够使用的处理器时间、内存大小、磁盘 I/O 速度等资源配额。这样不同空间内的进行就不会相互影响，实现了几乎完美的隔离。

隔离技术的应用：封装系统 or 封装应用？

2008 年 Linux Kernel 2.6.24 内核刚刚开始提供 cgroups 的同一时间，就马上发布了名为 Linux 容器 (LinuX Containers，LXC) 的系统级虚拟化功能。用来为用户提供虚拟化的操作系统服务。

而在 linux 设计者所设计的用来封装系统的技术，却被 docker 的设计者设计成了封装应用的工具。Docker 定义了一种将应用及其所有的环境依赖都打包到一起的格式，并利用 Linux 所提供的这些技术实现了应用的无依赖部署。

Docker 封装应用而非封装机器的优秀理念贯穿了它的设计、API、界面、文档等多个方面。相比之下，LXC 将容器视为对系统的封装，这局限了容器的发展。

正是 Docker 这种优秀的设计理念，使他在使用与 LXC 几乎相同的技术的基础上获得了巨大的成功，成为软件开发、测试、分发、部署等各个环节都难以或缺的基础支撑。

容器编排：Kubernetes

随着时代的发展，分布式系统代替了传统的单体应用，应用程序的设计变得越来越复杂，部署，运维等各个环节的成本和难度都指数级别提高。

Docker 的设计天生没有考虑由众多机器组成的集群环境，所以无法胜任调度大型集群的任务。

但是它”以应用为中心 “的理念和让应用无依赖部署的能力，却让 “在集群维度上自动调度应用程序” 成为可能。这种工作，我们称之为容器编排。

2014 年 6 月，Google 使用 Golang 重写其内部已运行多年的集群管理系统 Borg 后，更名为 Kubernetes 并开源，正式开启了容器安排的时代。2015 年 7 月，Kubernetes 发布了第一个正式版本 1.0 版，随后以摧枯拉朽之势覆灭了容器编排领域的其他竞争对手，成为现代服务编排调度的事实标准平台。

Kubernetes 的问题

然而，“No Silver Bullet。”，Kubernetes 也并不是完美的。

基于分布式系统本身的复杂性，Kubernetes 被诟病得最多的就是复杂，自诞生之日起就以陡峭的学习曲线和浩如烟海的概念而闻名。

而云原生基础设施的其中一个重要目标是接管掉业务系统复杂的非功能特性，让业务研发与运维工作变得足够简单，不受分布式的牵绊。

所以，Kubernetes 并不是云原生发展的终极形态，想达到这个目标，还有很远的路要走。

2. Sealos 的产生与发展

初始设计：集群安装工具

Kubernetes 的复杂性体现在很多方面，而安装是其中一个非常重要的方面。

使用 kubeadm 工具安装集群的基本流程如下：

1. 配置机器：包括主机名解析，ssh 免密登陆，禁用交换分区等。
2. 所有节点上安装 docker
3. 在所有节点上安装 kubeadm，kubelet 和 kubectl
4. 使用 kubeadm 在 master 节点上初始化控制平面
5. 配置 kubectl 非 root 访问权限
6. 安装 pod 网络插件
7. 使用 kubeadm 将 worker 节点加入集群中

…….

在这个过程中的每一步都可能会遇到各种各样的问题。非常的复杂和繁琐，足以劝退很多希望学习和使用 Kubernetes 的人员和企业。

而 Sealos 最初是为了解决该问题编写的命令行工具 (一开始它还叫 KubeInit)，它通过引入集群镜像的概念 (把整个集群视作一个镜像，像 docker 镜像那样处理) 与对安装集群中的每一步做的并发/容错的细致配置，达到了一键，快速，安全安装集群的功能。

使用 Sealos，用户只需要一条命令就可以完成整个集群的安装。而且大大缩短了安装的时间。(安装 6 个节点的集群只需要 3min 左右)，

通过在用户与 Kubernetes 之间充当中间层的方式，降低了其安装的复杂性。

那么我们不禁要进一步思考：既然 Kubernetes 安装的复杂性可以通过这种方式被降低，那么它的其他功能是否可以同样通过这种方式降低呢？

视角转变：将 Kubernetes 视为云内核

Kubernetes 出现的时候，很多人都将其视为云原生时代的操作系统，这种说法并不是空穴来风。

通过上文我们可以知道，操作系统的基本功能有：进程管理，内存管理，文件管理等等，说 Kubernetes 是操作系统，那么它首先要实现这些操作系统的基本功能，那么它实现的如何呢？

• 进程管理：Kubernetes 使用 Pod (容器组) 为单位调度应用程序，并可以通过 HPA 等技术实现动态扩缩容。
• 内存管理：与进程管理类似，在容器层面对应用程序的内存进行限制。
• 文件系统：Kubernetes 名为存储卷的集群全局资源管理持久化文件，并通过 PVCS,PVS 等应用程序”租赁 “的概念限制其使用。
• 设备管理：存储 I/O 主要与文件系统绑定实现，而网络 I/O 则通过 Service.Ingress 等概念进行分配和限制。
• 应用程序接口：应用程序不直接与 Kubernetes 进行交互，而是与各自节点上的 Linux 系统进行交互实现系统调用等功能。

由此可见，Kubernetes 确实有被称之为操作系统的资格。

但是让我们回想一下当前主流的操作系统：Linux，Macos，Windows，Android….

这些操作系统出了能完成基本功能外，不仅使用起来特别简单，而且几乎都带有图形化界面 (使用 Linux 桌面的人也越来越多)，学习成本很低甚至完全不需要学习。从这个维度上说，Kubernetes 无法被称之为一个优秀的操作系统，只能被视为 “云内核”，即优秀的操作系统内核。

根据之前的经验，隔离复杂性的最好方式就是分层，那么我们为什么不通过封装 Kubernetes 各种操作，编写各种功能强大的 CRD 与控制器，以更加用户友好的方式提供服务，成为 Kubernetes 中间层的方式，以 Kubernetes 优秀的能力为内核，打造出功能更加强大，用户更加友好的操作系统呢？

于是 Sealos 出现了。

Sealos 是一款以 Kubernetes 为云内核的云操作系统，无论是安装，还是部署或者运维应用程序，它使用起来都像 Linux 等单机操作系统一样方便而快捷。甚至完全不懂 Kubernetes 的人也可以使用它快速的部署和运维分布式应用程序。可以说，Sealos 补齐了用户使用 Kubernetes 作为操作系统的最后一块拼图，极大的降低了使用的门槛。

简单，是 Sealos 的第一个核心优势。

公有云服务：弹性计算

公有云是一种云计算服务模式，它允许多个用户通过互联网访问和使用云服务提供商提供的整套计算资源。

随着云原生技术的发展，公有云的市场规模不断增长，其按需付费，弹性计算的优势逐渐体现。

但是当前的主流公有云存在如下几个问题：

• 以虚拟机为主，系统资源占用过多
• 使用和配置比较繁琐，用户界面不太友好
• 弹性计算能力相对较差

那么为什么不让公有云用户共用同一个 Kubernetes 集群呢？用户仅需要为正在运行的容器付费，而不需要额外支付其他的费用。

这样做的优势是显而易见的：

• 使用容器可以避免虚拟机消耗的费用，避免不必要的操作系统消耗
• 基于 Kubernetes 强大的调度能力与 HPA 等功能，可以实现更加快速的应用弹性部署

但是众多的云厂商并不会选择这么做，主要也有两个原因：

• 多租户体系风险：在公有云不可信网络中使用多租户架构，存在隔离，鉴权，计费等各个问题。
• 用户操作难度高：原本使用虚拟机层级的服务配置已经足够复杂，而如果使用 Kubernetes 原生的相关概念去面向用户提供服务，繁多的 Pod,Deployment,Service,Ingress……等必须要用到的概念就足已劝退用户。

而对 Sealos 来说，其简单优秀的操作体验天然就可以可以解决操作难度的问题。所以 Sealos 的设计理念天然的就有提供公有云服务的优势。

而其又使用独特的用户体系设计在很大程度上解决了多租户体系风险。所以其可以为用户提供优质的公有云服务。在提供极简。可视化操作的同时，又借助 Kubernetes 强大的调度能力提供了比其他云服务更强的弹性能力，可以使应用程序自动在业务高峰期新增实例，低谷期削减实例，大大节省用户的部署成本。

弹性，是 Sealos 的第二个核心优势。

3. 展望未来：云原生的终极形态

随着技术的进步与 Sealos 这种云操作系统的出现，未来的云原生服务，一定会变得更加的简单，更加的弹性，更加的安全。

从软件制造角度上看，软件让我们的生活变得更加的简单，这意味着需要软件服务商提供更多的功能。

同理，从云服务的角度上看，云服务则让软件的设计，开发，运维变得更加的简单，这意味着需要云原生服务商提供更多的功能。

所以未来，我们会不断拓展 Sealos 的功能，不断优化用户的使用体验，提升服务的稳定性与安全性。以期达到云原生的终极形态。

在人类发展的历程中，世界需要的是核心业务和核心技术的改造与创新，而云原生，最终会极大程度的削减用户的心智负担，让软件的设计，开发，运维变得越来越简单而值得信赖，从而催生出更加优秀的设计，并变为现实，提供更加优秀的产品。