共计 6115 个字符，预计需要花费 16 分钟才能阅读完成。
作者 | fanux. 中弈, sealos 作者，pouch maintainer, sealer 创始人
我的项目地址：https://github.com/alibaba/se…
什么是集群镜像
顾名思义和操作系统.iso 镜像或者 Docker 镜像相似，集群镜像是 用肯定的技术手段把整个集群的所有文件以肯定格局打成的一个资源包 。
比照单机和集群会发现一些乏味景象：
- 单机有计算存储网络这些驱动，集群有 CNI/CSI/CRI 的实现像是集群的驱动
- 操作系统单机有 ubuntu centos 这些，咱们能够把 kubernetes 看成云操作系统
- 单机上能够运行 docker 容器 或者是虚拟机，相当于一个运行的实例，集群也有运行着 k8s 的实例
- 单机上的虚拟机镜像，docker 镜像，所以随着云计算技术的倒退，在集群这个纬度也会形象出相似的镜像技术。
以基于 kubernetes 的集群镜像为例，外面蕴含了除操作系统以外的所有文件：
- docker 的依赖的二进制与 systemd 配置，dockerd 的配置，以及一个公有的容器镜像仓库
- kubernetes 外围组件二进制，容器镜像，kubelet system 配置等
- 利用须要用到的 yaml 配置或者 helm chart，以及利用的容器镜像
- 其它脚本，配置与二进制工具等利用运行须要的所有依赖
同样集群镜像运行时必定不是起一个容器或者装在一台机器上，而是这个镜像能够间接装置到多台服务器上或者间接对接到私有云的基础设施上。
sealer 介绍
sealer 是阿里巴巴开源的集群镜像的一个实现形式，我的项目地址：https://github.com/alibaba/se… 要实现集群。
Docker 解决了单个容器的镜像化问题，而 sealer 通过把 整个集群打包，实现了分布式软件的 Build Share Run!!!
试想咱们要去交付一个 SaaS 利用，它依赖了 mysql es redis 这些数据库和中间件，所有货色都在 kubernetes 上进行编排，那如果没有集群镜像那要做如下操作：
- 找个工具去装置 k8s 集群
- helm install mysql es redis… 如果是离线环境可能还须要导入容器镜像
- kubectl apply yoursaas
看似如同也没那么简单，然而其实从整个我的项目交付的角度来说是面向过程极易出错的
那当初如果当初提供另外一个形式只有一条命令解决下面的问题你会不会用？sealer run your-saas-application-with-mysql-redis-es:latest
能够看到只须要 run 一个集群镜像整个集群就被整体交付了，细节简单的操作都被屏蔽掉了, 而且任何利用都能够应用雷同的形式运行。那这个集群镜像是怎么来的呢：
咱们只须要定义一个相似 Dockerfile 的文件咱们称之为 Kubefile, 而后执行一下 build 命令即可：sealer build -t your-saas-application-with-mysql-redis-es:latest .
在单机和集群两个纬度进行一个比照就能够高深莫测：
docker 能够通过 Dockerfile 构建一个 docker 镜像，应用 compose 就能够运行容器。
sealer 通过 Kubefile 构建一个 CloudImage, 应用 Clusterfile 启动整个集群。
疾速体验
制作和运行一个 kubernetes dashboard 的集群镜像来体验一个残缺的流程。
编写 Kubefile
# 根底镜像，曾经被制作好了外面蕴含所有的 kubernetes 启动相干的依赖
FROM registry.cn-qingdao.aliyuncs.com/sealer-io/cloudrootfs:v1.16.9-alpha.7
# 下载官网的 dashboard yaml 编排文件，曾经下载了能够应用 COPY 指令
RUN wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
# 指定运行形式，能够应用 kubectl helm kustomiz 等
CMD kubectl apply -f recommended.yamlbuild dashboard 集群镜像sealer build -t kubernetes-with-dashobard:latest .
运行集群镜像
# 上面命令会在服务器上安装 k8s 集群并 apply dashboard, passwd 指定服务器 ssh 明码, 也能够应用密钥
sealer run kubernetes-with-dashobard:latest \
--master 192.168.0.2,192.168.0.3,192.168.0.4 \
--node 192.168.0.5,192.168.0.6 \
--passwd xxx
# 查看 pod
kubectl get pod -A |grep dashboard
把制作好的镜像推送到镜像仓库，兼容 docker registry
sealer tag kubernetes-with-dashobard:latest docker.io/fanux/dashobard:latest
sealer push docker.io/fanux/dashobard:latest这样就能够把制作好的镜像交付进来或者提供给他人复用。
应用场景
sealer 具体能帮咱们做哪些事呢，上面列举几个次要场景：
| 装置 kubernetes 与集群生命周期治理 (降级 / 备份 / 复原 / 伸缩)
这是个最简略的场景，不论你是须要在单机上安装个开发测试环境还是在生产环境中装置一个高可用集群，不论是裸机还是对接私有云，或者各种体系结构操作系统，都能够应用 sealer 进行装置，这里只装置 kubernetes 的话就抉择个根底镜像即可。
与其它的装置工具比照，sealer 劣势在于：
- 简略到令人发指 sealer run 一条命令完结
- 速度快到令人窒息，3min 装完 6 节点，可能你在应用别的工具还没下载完 sealer 就曾经装完了，然而咱们后续还有黑科技优化到 2min 甚至 1min 以内
- 兼容性与稳定性 兼容各种操作系统，反对 x86 arm 等体系结构
- 一致性设计，会让集群放弃 Clusterfile 中的定义状态，以降级为例，只须要改一下 Clusterfile 中的版本号即可实现降级。
速度快是因为首先是 golang 实现，意味着咱们能够很多很粗疏的中央做并发的解决，这相比 ansible 就有更多的劣势了，而且还能够做更粗疏的错误处理，而后在镜像散发上摈弃了以前 load 的形式，后续在文件散发上也会做优化达到装置性能上的极致。
兼容性上，docker kubelet 这里都采纳了二进制 +systemd 装置外围组件全容器化，这样不必再去依赖 yum apt 这类感知操作系统的装置工具。ARM 和 x86 采纳不同的镜像反对与 sealer 自身解耦开。对私有云的适配也抽离独自模块进行实现，这里咱们没去对接 terraform 起因还是为了性能，在咱们的场景下 terraform 启动基础设施将近 3min，而咱们通过退却重试把基础设施启动优化到了 30s 以内，还有就是在集群镜像这个场景下是不须要这么简单的基础设施治理能力的，咱们不想让 sealer 变重也不想去依赖一个命令行工具。
一致性的设计理念是 sealer 中值得一提的，集群镜像与 Clusterfile 决定了集群是什么样子的，雷同的镜像与 Clusterfile 就能 run 出个一样的集群进去。变更要么变更 Clusterfile 如减少节点，扭转节点规格，要么换镜像，换镜像的时候因为集群镜像也是分层构造，hash 值不变的 layer 不会产生变更，而 hash 发生变化会帮忙从新 apply 该层。
| 云原生生态软件的打包 / 装置等如 prometheus mysql 集群等
sealer run prometheus:latest 就能够创立一个带有 prometheus 的集群，或者在一个已有的集群中装置 prometheus。
那么问题来了：和 helm 啥区别？
- sealer 不关怀编排，更重视打包，下面例子 prometheus 能够用 helm 编排的，sealer 会把 chart 和 chart 外面须要的所有容器镜像打包起来，这是在 build 的过程中通过黑科技做到的，因为 build 过程会像 docker build 一样起长期的 kubernetes 集群，而后咱们就晓得了集群依赖了哪些容器镜像，最初把这些容器镜像打包。
- 和 kubernetes 一起打包，拿了一个 chart 它未必能装置胜利，比方应用了废除的 api 版本，然而做成镜像把 kubnernetes 也包在一起了，只有 build 没问题，run 就没问题，这点和 docker 把操作系统 rootfs 打包在一起殊途同归。
- 集成性，集群镜像更关注整个分布式应用集群整体打包，如把 prometheus ELK mysql 集群这些做成一个镜像服务与业务。
所以 sealer 与 helm 是协作关系，分工明确。
后续就能够在 sealer 的官网镜像仓库中找到这些通用的集群镜像而后间接应用。
| SaaS 软件整体打包 / 交付 专有云离线交付
从分布式应用的视角看，通常从上往下，少则几个多则上百的组件，现有整体交付形式大多都是面向过程的，两头须要很多认为干涉的事，sealer 就能够把这些货色通通打包在一起进行一键交付。
可能你会问，我做个 tar.gz 再加个 ansible 脚本不也是能一样一键化嘛，那是必定，就和 docker 镜像呈现之前大家也通过 tar.gz 交付一样，你会发现规范和技术的呈现解决和人与人之间的合作问题, 有了集群镜像你能够间接复用他人的成绩，也能制作好货色做他人应用。
专有云场景就非常适合应用 sealer，很多客户机房都是离线的，而集群镜像会把所有依赖打到镜像中。只有镜像制作的好那所有局点都能够以雷同的形式进行一键交付，取得极佳的一致性体验。
| 在私有云上实际上述场景
sealer 自带对接私有云属性，很多状况下对接私有云会有更好的应用体验，比方装置集群时只须要指定服务器数量和规格而不必关怀 IP，伸缩间接批改 Clusterfile 中定义的数字即可。
技术原理简介
| 写时复制
集群镜像的存储也是通过写时复制的形式，这样做有两个益处，咱们能够把一个集群中不同的分布式式软件打在不同的层，以实现复用，还能够实现间接把集群镜像 push 到 docker 镜像仓库中。
| 容器镜像缓存
build 的过程中 sealer 是如何晓得待构建的集群镜像里有哪些容器镜像，以及怎么把容器镜像存储下来，这其中有一些难点问题:
- 如何晓得分布式软件中有哪些容器镜像，因为咱们须要把这些镜像缓存下来，不论是扫描用户的 yaml 文件还是用 helm template 之后扫描都是不完满的，首先不能确定用户的编排形式是什么，其次有些软件甚至不把镜像地址写在编排文件中，而是通过本人的程序去拉起。无奈保障 build 胜利运行就肯定没问题。
- 容器镜像是须要被存储到公有仓库中打包在集群镜像里，那容器镜像仓库地址势必和编排文件中写的不一样，特地是怎么保障用户 alwayPull 的时候还是可能在公有仓库中下载到镜像。
看待第一个问题，sealer 解决形式是 sealer build 的过程中和 Docker build 一样会起一个长期的 kubernetes 集群，并执行用户在 Kubefile 中定义的 apply 指令。
这样就能够保障用户依赖的所有镜像都被打包进去，无论用户应用什么样的编排形式。
第二个问题，咱们打包容器镜像到公有镜像仓库中，怎么应用这个公有镜像也是个问题，因为假如公有镜像仓库名为 localhost:5000 那必定会和编排文件中写的不一样，咱们有两种形式解决，第一种是 hack 和 docker，做了一个只有公有镜像仓库中有就间接从公有镜像中拉取，没有才去公网拉取镜像的能力。
还有种计划是无侵入 docker 的 proxy, 把 docker 申请全部打给代理，让代理去决定如果公有仓库有就从公有仓库拉取。同时咱们还加强了 registry 的能力让 registry 能够 cache 多个近程仓库的能力。
sealer 的这种计划完满的解决了离线场景镜像打包的问题。
| 负载平衡
sealer 的集群高可用应用了轻量级的负载平衡 lvscare，首先相比其它负载平衡 lvscare 十分小几百行代码，而且 lvscare 只做 ipvs 规定的守护，自身不做负载十分稳固，间接在 node 上监听 apiserver，如果跪了就移除对应的规定，从新起来之后会主动加回，相当于是一个专用的负载均衡器，在 sealos 我的项目中也用了两年多，有宽泛的实际。
| 运行时
运行时就是撑持利用运行的环境，像 base on kuberentes 的运行时 sealer 就能够通明的反对非常简单，以 istio 为例，用户只须要：
FROM kubernetes:v1.18.3
RUN curl -L https://istio.io/downloadIstio | sh -就能够 build 进去一个 istio 的运行时供本人利用应用。
对于不是 base on kuberentes 的运行时，如 k0s k3s，能够扩大 sealer.Runtime 中的接口，这样当前就能够：
FROM k3s:v1.18.3
RUN curl -L https://istio.io/downloadIstio | sh -更牛的扩大比方扩大 ACK 的 runtime
FROM aliyum.com/ACK:v1.16.9
RUN curl -L https://istio.io/downloadIstio | sh -这种镜像会间接帮忙用户利用运行到 ACK 上。以上有些能力在 roadmap 中
| 基础设施
当初很多用户都心愿在云端运行本人的集群镜像，sealer 自带对接私有云能力，sealer 本人实现的基础设施管理器，得益于咱们更精密的退却重试机制，30s 即可实现基础设施构建 (阿里云 6 节点) 性能是同类工具中的佼佼者，且 API 调用次数大大降低，配置兼容 Clusterfile。
总结
sealer 将来的一些愿景与价值提现：
- sealer 能够以极其简略的形式让用户自定义集群，解决分布式软件制作者与使用者的合作问题。
- 极其简略敌对的 User Interface, 能屏蔽和兼容各种底层技术细节，到处运行
- 生态建设，官网仓库里将会涵盖罕用的分布式软件
最初咱们总结下：
- 如果你要整体交付你的分布式 SaaS，请用 sealer
- 如果你要集成多个分布式服务在一起，如数据库音讯队列或者微服务运行时，请用 sealer
- 如果你要装置一个分布式应用如 mysql 主备集群，请用 sealer
- 如果你须要装置 / 治理一个 kubernetes 高可用集群，请用 sealer
- 如果你要初始化多个数据中心，放弃多个数据中心状态强统一，请用 sealer
- 如果你须要在私有云上实现上述场景，请用 sealer
kubernetes 一键装置