作者：方海涛（中弈）
议题简介：集群镜像把整个集群看成一台服务器，把 K8s 看成云操作系统，实现整个集群的镜像化打包和交付，为企业级软件提供一种“开箱即用”的应用封装技术。以行业 ISV 为例，集群镜像帮助企业解决了分布式软件的部署一致性难题、降低了交付出错率，最终指数级降低分布式软件的交付成本。 受docker等容器技术的启发，集群镜像将单机应用封装技术，上升到分布式集群维度，最终实现分布式软件的高效交付（build, share, run)。
分享人：
方海涛（中弈），sealer项目发起人，阿里云技术专家，拥有七年以上云原生从业经验，sealos 作者，数千家企业在生产环境中使用该项目。
目录：
• 背景介绍
• 应用交付困局
• Sealer-集群镜像介绍
• 总结与规划
一、背景介绍
从应用视角看云的发展历程，就是一个不断屏蔽底层细节的过程。
• 最早是物理机；
• openstack：做了资源虚拟化，但并未对应用管理做思考，注重了利用率；
• Docker：主要考虑针对单个应用的打包；
• kubernetes：管理整个集群，向下整个资源做抽象，向上整个分布式应用做管理，如何
部署、升级、配置等；
• Serverless：聚焦业务逻辑，几乎对服务端运维管理不操心，更聚焦业务本身；
• Wasm DApp：区块链里的合约和faas似乎朝着一个方向发展最终可能在某个点融合，大家关心的更少，直接把应用发布到运行着的世界计算机上；
业务只关心业务逻辑的一个不断迭代过程。最终云原生可以用极小的成本让业务简单开发稳定运行。
二、应用交付困局
1. 应用交付目前存的问题：交付周期长，交付成本高
a. 定制性/灵活性差：真正交付时不清楚客户需要的是什么，比如集群里包含哪种数据库，数据库架构是怎样的，配置是怎样的。还要与自己的SaaS软件无缝结合；
b. 协作困难：交付者和研发者不清楚彼此之间的功能逻辑需求等；
c. 交付一致性差：在测试环境正常，到客户环境中，可能会出现网络不通，缺少依赖等问题，导致无法正常交付，Docker只是解决了部分，并未彻底解决；
2. Docker解决了一致性问题?
Docker仅解决了单个应用的镜像化问题，对于软件整体来说是包含非常多分布式组件的，并不能在整个集群纬度保证一致性。
3. Kubernetes解决了什么问题?
Kubernetes很好的解决了分布式应用管理和资源的抽象问题，应用之间复杂的应用如何编排；然而对于交付而言这还远远不够，比如kubernetes本身如何最佳交付都是个问题，还有上面庞大的应用编排文件与镜像如何交付？
4. Helm解决了应用整体编排但不打包
Helm只是把编排文件打包和参数的抽离，很好的管理了编排文件，但是并不会把所有依赖都管理起来，比如helm不会帮你管理k8s本身的交付，也不会帮你管理私有镜像仓库和集群中需要的镜像甚至二进制如何打包。更不会帮你处理交付时一些常规的操作如修改主机名，时间同步等。
三、 Sealer - 集群镜像介绍
定义：如同Docker或者虚拟机镜像一样，把整个集群当成一台机器把kubernetes当成操作系统，整个集群所有依赖整体打包的技术称之为集群镜像。
1. 集群镜像介绍
如上对比图所示：
• 驱动层：单机上有计算、存储、网络驱动，集群里是K8s容器运行CRI、CNI、CSI时的实现；
• 操作系统层：单机有ubuntu centos，集群里是Kubernetes；
• 容器层：单机是Docker镜像，集群里运行着K8s的集群；
• 镜像层：单机是Docker镜像，而集群里是缺失的环节。
2. 集群镜像工作流
• 单机：书写Dockerfile，构建DockerImage，通过Docker Compose告诉如何去使用DockerImage，就可以run Docker，镜像可变动部分很少，通过Compose去灵活的控制操作；
• 集群：书写Kubefile，构建CloudImage，此镜像包含了该云需要的所有资源，对接Clusterfile，Clusterfile告知了云在运行时需要哪些参数，需要运行在哪些服务器上，或者是对接一个什么样的公有云，包括应用启动时Redis等的配置，去启动运行整个集群。启动运行包括上层所有依赖的数据库、中间件、SasS应用等。
Sealer最核心价值是将其中比较复杂的面向过程的细节全部像Docker一样进行了封装，但却是集群维度的，所有的依赖都会在集群镜像中。
3. 集群创建
定义一个类似于Docker文件的kubefile（如上图左边所示），进行创建Sealer集群镜像，包含了内嵌的kubernetes和它的所有依赖，到客户环境中，只需要提供好机器，装好操作系统，连接好网络就可以去运行Sealer。
4. 集群分享与运行
如上图交付过程，将创建好的集群镜像可以push到Docker的Redis，再pull或者save下来，save下来就是一个tar包，tar包到了客户环境可以load，这样就保证了在离线环境中同样可以把集群拉起来，配合Clusterfile，进行run。
5. Sealer发展历程
• 2020年5月：Sealer 项目的想法诞生；
• 2020年12月：开始设计，最初版本只有十几条指令，经过优化筛选，目前剩余5条，极大程度的降低了使用门槛，有Docker基础的使用者，能够很快明白上手；
• 2021年3月：代码开源；
• 2021年6月：发展了40多位开发者，30多位企业客户，同时也发展了20多个通用的CloudImages，包括MySQL，Redis等，在其列表中拿来使用就可以，在通常情况比如在使用SaaS软件时，可能同时需要MySQL和Redis，Sealer做的比较好的一点就是可以把你所需要的组合在一起，该镜像就可以专门服务于你。所以说Sealer 具有很好的灵活性和可组装性；
• 2021年9月：生产环境落地，有两个用户已经在生产环境中落地。
6. 高可用
• 在做高可用的时候不用再去依赖过重的组件；
• 如果启用Nginx做反向代理，流量会走Nginx的进程，当进程出现问题会影响整体的可用性，而ipvs负载只要内核在运行，上层管控组件出现问题时不会影响整个集群的高可用。
7. 容器镜像缓存机制
- 传统方式交付一个新集群就需要对镜像地址进行修改，否则无法拉取到容器镜像；
- 在打包时也需要对镜像地址进行修改；
- Sealer采用完全透明的兼容方式让用户完全不用关心存储镜像的过程，整个构建和交付的过程不用修改任何镜像地址。
8. 插件机制
如上图所示，在集群交付时，总会有一些不通用的功能，比如：修改主机名称等。类似的需求可以做成对应的插件，也可以扩展出相应的插件。
9. 配置管理机制
在交付Redis时，账户密码等有变更，同样可以在Clusterfile中去定义一个Config，可以覆盖掉镜像里的任何的文件，不管是Helm的values，还是etcd里的文件或者修改自定义的文件。Sealer的配置能力非常灵活，而且不会限制到底是使用哪种编排工具。
四、总结与规划
1. 客户列表
很多客户使用sealer极大的提升了交付稳定性和交付效率，把一周左右的交付周期缩短到了小时级别。
2. Roadmap未来规划
• V1.0版本发布：着重在整个核心功能，充分测试，高性能，高稳定性；
• 生态系统：让CloudImage足够多，更好用，比如让MySQL、Redis等更好用；
• 社区推动：推动社区开发者，尽量把Sealer作为默认的安装方式，一键交付到客户的集群中。
3. 总结
为什么要使用集群镜像？
• 高质量可复用的镜像；
• 自定义灵活组装；
• 分钟级交付；例如在对接公有云时，传统方式3分钟把资源拉起来，而Sealer优化了并发，只需要30秒，在分发上性能也更高；
• 标准化协作：在集群维度软件的生产者直接制作镜像就可以很简单的被消费者消费；
• 广泛的适配性兼容性：几乎兼容了Linux支持Systemd的绝大多数版本；
使用集群镜像可以让大家在交付专有云的时候，不受技术的限制，降低交付成本，缩短交付周期，最终帮助SaaS软件或专有云交付场景，实现规模化，扩大利润，这是Sealer的终极目标。
