Sealer - 把kubernetes看成操作系统集群纬度的Docker

作者介绍：中弈，sealos作者，sealer项目发起人。

写在开头

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

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

sealer为什么会诞生

云的背景与趋势

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

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

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

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

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

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

交付领域的痛点与刚需

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

目前专有云交付面临的三大困局，Docker kubernetes helm这些技术虽然解决掉了一部分痛点，但是并不彻底。 Docker仅解决了单个应用的镜像化问题，对于软件整体来说是包含非常多分布式组件的，这块docker不管 Kubernetes很好的解决了分布式应用管理和资源的抽象问题，应用之间复杂的应用如何编排，但是庞杂的编排配置如何管理？ Helm只是把编排文件打包和参数的抽离，但是并不会把所有依赖都管理起来 所以即便你使用了上述技术，一旦到了真实场景，一样会焦头烂额。

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

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

优秀的设计理念

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

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

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

sealer的价值

帮助企业实现规模化交付

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

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

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

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

打破协作壁垒

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...如果失败那就是研发人员镜像没制作好，锅甩回去就行，有了标准分工明确。另外对于交付人员的要求也会变的极低，实习生培训半天上岗。

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

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

各种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理念的认可。

极简的用户使用接口设计

遵循大道至简的设计理念，我们吸取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如何灵活的分组等。当然还有一些其他的字段没有展示出来，原则上不给不需要关注其它功能的用户增加负担，需要用什么样的能力才去关心什么样的参数。

优秀的插件机制

我们一些总会遇到一些非常奇葩的需求，极不通用，但是又是客户刚需，你支持的话又会让你的架构变乱，让整个产品变得“不优雅”，影响到别的用户使用体验。这个时候就必须通过强大的设计能力把这些功能剥离开，让不需要用它的人完全感知不到它的存在。

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

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

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

极致的性能极致追求

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

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

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

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

等等，我们为了用户极致体验，煞费苦心。。。

写在最后

简单又强大的产品总是能抓住用户的心，sealer不仅需要解决核心的痛点问题，还需要让用户获得极佳的使用体验。

功能上sealer已经完成了“集群纬度的Docker”这一设定，未来在生态发展上会增加更多的投入，创造更多更优质的官方镜像，建立更多的合作伙伴，真正把软件的提供者与使用者连接起来，高效的协作。 kubernetes一键安装

sealer集群整体打包！