Sealer - 把 Kubernetes 看成操作系统集群维度的 Docker - JavaScript

小程序：扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序

作者 | 中弈

写在开头

身为一名技术人员，总是喜欢把自己的作品打造成理想状态呈现给别人，我非常荣幸能把集群镜像这样一个卓越的想法变成现实, 也非常开心用户使用我们的作品时对我们的高度认可。

Sealos 虽然已经超过 5k 星，数千家客户在生产环境中使用，不乏很多一线互联网公司和大厂。曾经 sealos 也令我很激动，我把一件复杂的事情做到的极简，这是核心竞争力，即便如此我还是不会夸它，因为在 sealer 面前它黯然失色。

Sealer为什么会诞生

1、云的背景与趋势

从应用的视角看，云的发展历程就是一个不断屏蔽底层细节让应用更关注业务逻辑本身的一个过程。

Openstack 让开发者不用再关心物理机复杂的管理问题，但是并未在应用本身管理在有任何改善，对于应用开发者依然需要和操作系统打交道。

Docker 的出现掀起了一场云架构的革命，穿透了传统的 IaaS、PaaS，让分层变模糊，此时已经帮助应用实现一些打包隔离工作，一定程度让应用变得更容易管理。

Kubernetes 的出现让云从分层架构走向“云内核”架构，云操作系统逐渐显现，对下实现计算网络存储这些资源的抽象，对上实现应用的编排管理。此时应用的配置管理，服务发现，资源配置变得更为简单，发布分布式应用变得像发布单机应用一样流畅。

Serverless FaaS 的出现就让应用更聚焦于业务逻辑本身了，只是目前还没能出现像 Kubernetes 一样的实际标准性的东西，还处在百家争鸣的阶段。

有意思的地方的区块链领域的智能合约，以太坊的 EVM 第一代合约天生就是 serverless，运行在以太坊这个世界计算机上。而以 Polkadot solana near ICP 这样为代表的二代合约支持了 WASM 打破了 EVM 的场景局限，让合约走向更通用的场景。所以非常期待云和链技术最终能在一个地方统一，实现真正意义上的“世界计算机”，所有应用都在这台“超级电脑上”运行。

2、交付领域的痛点与刚需

我们希望让 Kubernetes更简单，顺应技术大趋势让基于 Kubernetes 的交付变得更干净利索。

目前专有云交付面临的三大困局，Docker、Kubernetes、Helm 这些技术虽然解决掉了一部分痛点，但是并不彻底：

• Docke r仅解决了单个应用的镜像化问题，对于软件整体来说是包含非常多分布式组件的，这块 docker 不管；

• Kubernetes 很好的解决了分布式应用管理和资源的抽象问题，应用之间复杂的应用如何编排，但是庞杂的编排配置如何管理？

• Helm 只是把编排文件打包和参数的抽离，但是并不会把所有依赖都管理起来。

所以即便你使用了上述技术，一旦到了真实场景，一样会焦头烂额。

对于很多用户而言安装 Kubernetes 本身可能比装业务还复杂，那么多容器镜像如何管理，到了客户环境需要的依赖没人怎么办，一个一个组件安装人工误操作导致出问题概率大大提升。

所以非常需要一个集群整体打包成镜像的技术，在集群维度保障一致性。

3、优秀的设计理念

只有在伟大的想法诞生时你会为之激动，充满热情，想尽一切办法让它变成现实。

在设计 sealer 时想尽一切办法让它变得简洁干净但是还需要满足各种能力，就像要把很多复杂的技术融入到一个手机里一样，做减法才是考验一个人设计能力的地方。

Sealer 的理念也把大道至简和高度抽象阐述到了极致，确实以优雅的方式解决了很痛点的问题，符合行业大趋势且能创造巨大的生态价值。

Sealer 的价值

1、帮助企业实现规模化交付

对于专有云交付类的公司而言，sealer 最终能帮你实现的就是实现规模化交付，扩大营收，降低成本，提高利润。采用 sealer 技术的公司可以在规模化竞争中取胜，降低单次产品交付价格，创造核心价格优势。

以现有的交付类项目现状来看几乎都是几十万上百万起步，这几乎就把客户群体限制在头部客户了，但是对于中小企业需求是真实存在的，由于交付成本高导致出现这种有需求无市场的情况。如果价格能降低到数千或者几万，那新的市场就会完全被打开。

对于甲方来说也是一样，采购一套软件到落地都是数月的时间，和销售沟通、poc、交付等等，整个链路非常长。因为乙方的交付成本变低，相应甲方的采购成本也会降低。

在 sealer 出现之前想一年线下交付一万套复杂软件对于绝大多数企业而言几乎不可能完成，像小时级别的交付更是异想天开，但是 sealer 可以实现自助化，交付规模不再受技术水平限制，还能实现快速一键交付。

2、打破协作壁垒

Docker 出现之前就已经有非常多的容器技术了，为什么都没有出现席卷之势和颠覆效应？

很大一部分原因是标准的出现让生态之间的协作成为可能。Docker 镜像的出现让软件的生产者与交付者之间完美协同，我需要的任何东西都可以在仓库中找到，而我不再需要去关心里面的实现细节，使用者真的像一个老板一样只要结果。需要任何软件都无脑 docker run...

然而很多人尝试建立标准，绝大多数都失败了，但 docker 却成功了，为什么？因为一个标准快速普及在我看来通常需要满足一些基本原则：

第一：切中痛点

第二：简单极致

第三：不失强大

满足以上三点成为公认的标准的可能性会大大提升。

Docker 镜像标准把进程所有依赖打包，保障其一致性，这是交付中非常痛的地方。

同时满足 2 和 3 是非常困难的，Dockerfile 简简单单几条指令，你会发现虽然简单但是几乎可以打包任何东西。这就非常容易被广泛接受，如果一个标准动辄大几百页文档，用户看一眼就吓跑了更别说遵循了……

Sealer 的设计同样遵循以上三点。

痛点方面，sealer 取 docker 设计思想之精髓，能 docker 所不能，因为现代的软件几乎都是分布式应用，docker 并不关心分布式应用如何做成镜像，sealer 就专门以 K8s 为集群操作系统，把 docker 的思想衍生到集群维度，实现分布式软件的构建、打包、交付、运行等等。

简单极致，sealer 把奥卡姆剃刀运用到极致，指令删减到比 dockerfile 指令还少，也遵循 docker 的指令设计以更容易让用户接受，如果三分钟还没看懂 sealer 的 Kubefile 那就是 sealer 设计的失败。

sealer 简单但并非简陋，你会发现简单几条指令几乎可以帮助用户构建任何复杂的自定义 Kubernetes 集群和自定义分布式应用镜像，然后一键运行。

所以 sealer 必将建立成功的集群镜像交付标准，有了标准之后大家就可以相互更好的协作了。

在 sealer 出现之前，复杂应用设计的开发人员与交付人员之间总会有数不清的恩怨，前线交付人员不理解数十个业务之间的关系是怎样的，研发人员不知道前线的交付环境有多复杂，一旦出问题，就拉十几个人的在线会议……最后老板发现三个和尚没水喝。

有了 sealer 之后，研发人员制作好集群镜像，交付人员闭着眼睛 sealer run...如果失败那就是研发人员镜像没制作好，锅甩回去就行，有了标准分工明确。另外对于交付人员的要求也会变的极低，实习生培训半天上岗。

3、灵活的定制性、自由组合、复用性、一致性与兼容性

我们会制作很多基础镜像供你直接“拿来主义”：

各种 Kubernetes 版本，各种架构 ARM、AMD…

包含各种 CNI、CSI 实现的镜像，calico、flannel、openlocal、openebs…

各种生态软件镜像，高可用的mysql、redis、prometheus...

这些镜像并非是 docker 镜像，而是集群镜像，pull 下来就直接可以运行出一个集群！

更变态的能力是我们支持这些镜像的自由组合，比如你需要 calico+redis+mysql 的组合，那只需要 sealer merge 命令就可以把三个镜像合并在一起供你的业务使用。集群镜像就像玩泥巴一样，把几坨泥巴捏在一起还是一坨泥巴，高度的抽象能力令人叹为观止……

更更变态的能力是即便这些都不能满足你，你也只需要像写一个 Dockerfile 一样简单的去自定义你自己的集群里面包含什么，比如你想把自己软件的前后端服务也打到集群镜像中。而且你可以 FROM 已有的基础镜像来复用别人提供的能力。

而且 sealer 低层技术保障了这些镜像具备非常好的兼容性，可以在任何平台丝滑的运行起来。

如何把想法变成现实

sealer 仅发展半年多时间，就在社区吸引了四十多名开发者，三十多家试用客户，在两家生产环境中落地。

起初花了半年多的时间去做设计，写设计文档，这中间推翻了 N 个版本的设计，不断精简优化，每个指令设计都精雕细琢，严格遵循如无必要勿增实体。

设计完成之后还几乎是光杆司令，此时在一个月内迅速集结队伍，大部分是兄弟组成员，生态公司的开发者，如和谐云沟通时，非常认可我们的想法并决定投入人力，最终一个七人的虚拟组织诞生。密集的开发三个月之后诞生了首个版本并完成开源。

开源之后发展就更迅速了，快速聚集开源社区力量，吸引了很多外部开发者让项目快速收敛稳定，很快吸引了一批用户尝试，可见需求之强烈以及用户对于 sealer 理念的认可。

1、极简的用户使用接口设计

遵循大道至简的设计理念，我们吸取 docker 的设计思想，让集群镜像的制作和运行也变得非常简单。

构建集群镜像的 Kubefile，类似 Dockerfile 但是更简单，比如制作一个包含 calico 的集群镜像：

FROM kubernetes:v1.19.8-alpine COPY etc . RUN wget https://docs.projectcalico.org/manifests/tigera-operator.yaml CMD kubectl apply -f etc/tigera-operator.yaml CMD kubectl apply -f etc/custom-resources.yaml

如何启动集群的 Clusterfile，类似 Docker-compose：

apiVersion: sealer.cloud/v2 kind: Cluster metadata: name: default-kubernetes-cluster spec: image: kubernetes:v1.19.8 ssh: passwd: xxx hosts: - ips: [192.168.0.2,192.168.0.3,192.168.0.4] roles: [master] - ips: [192.168.0.3] roles: [node]

只需要配置集群镜像名称和服务器 IP 地址 ssh 信息即可拉起一个集群。这里面的每一行都透射出精雕细琢，ip 为什么使用列表，roles 如何灵活的分组等。当然还有一些其他的字段没有展示出来，原则上不给不需要关注其它功能的用户增加负担，需要用什么样的能力才去关心什么样的参数。

2、优秀的插件机制

我们一些总会遇到一些非常奇葩的需求，极不通用，但是又是客户刚需，你支持的话又会让你的架构变乱，让整个产品变得“不优雅”，影响到别的用户使用体验。

这个时候就必须通过强大的设计能力把这些功能剥离开，让不需要用它的人完全感知不到它的存在。

所以 sealer 设计出了强大的插件机制，让你爱干啥干啥但别影响别人。。

比如有些人非要想用 sealer 修改主机名，这其实压根也不属于 sealer 关心的范畴，那么就可以开发一个插件去做这个事，用户配置了这个插件就激活了这个功能：

还有用户说我想开发一个专用插件，但是不想把代码贡献给 sealer 社区，因为极不通用的能力，贡献也没有意义。这样的场景我们支持 golang plugin 机制，载入.so 文件实现插件的动态加载。

3、极致的性能极致追求

虽然我们在集群构建的过程中已经速度非常之快了，几分钟六节点几乎是性能的极限了，然而用户体验是否丝滑，这一块的影响非常之大，所以并没停止性能方面的追求。

比如 terraform 对接公有云需要 2-3min 起基础设施，我们觉得这太不可接受，自己重新写了 driver 把这个时间缩短到了 30s 以下，这已经几乎是极限了，再要提升就受限于服务端启动虚拟机速度了。我们做了退避等待与更合理的并发机制达到这种性能。

比如集群镜像如 docker 一样会分层拉取镜像，提高层复用提升性能。文件拷贝的过程占用非常大的时间，我们做了一些按需拷贝的功能。未来准备对接 nydus 的一些能力实现懒加载和 P2P 分发集群镜像，进一步提升性能。

比如 Build 集群镜像过程中需要缓存容器镜像，传统的做法是 pull 再 push 显然多做了一些无用功，我们就采用代理直接 cache 下来，pull 的过程直接缓存，但是 build 的时候需要起 registry 还是不够极致，未来我们会直接集成核心代码，在不启动 registry 的情况下即可缓存。

以上种种，说明我们为了用户的极致体验，可谓是煞费苦心……