共计 5345 个字符，预计需要花费 14 分钟才能阅读完成。
作者介绍：中弈，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”这一设定，将来在生态倒退上会减少更多的投入，发明更多更优质的官网镜像，建设更多的合作伙伴，真正把软件的提供者与使用者连接起来，高效的合作。
sealos 以 kubernetes 为内核的云操作系统发行版，让云原生简略遍及
laf 写代码像写博客一样简略，什么 docker kubernetes 通通不关怀，我只关怀写业务！
