关于docker:集群镜像实现高效的分布式应用交付

简介：Docker 解决了单个容器的镜像化问题，而 sealer 通过把整个集群打包，实现了分布式软件的 Build Share Run。

作者 | fanux. 中弈

什么是集群镜像

顾名思义，和操作系统 .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 上进行编排，如果没有集群镜像时，要做如下操作：

1. 找个工具去装置 K8s 集群
2. helm install mysql es redis… 如果是离线环境可能还须要导入容器镜像
3. 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.yaml

build 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 劣势在于：

1. 简略到令人发指：sealer run 一条命令完结。
2. 速度快到令人窒息：3min 装完 6 节点，可能你应用别的工具时还没下载完 sealer 就曾经装完了，不仅如此，后续咱们还有黑科技优化到 2min 甚至 1min 以内。
3. 兼容性与稳定性：兼容各种操作系统，反对 x86 arm 等体系结构。
4. 一致性设计：会让集群放弃 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 啥区别？

1. sealer 不关怀编排，更重视打包，下面例子 prometheus 能够用 helm 编排，sealer 会把 chart 和 chart 里须要的所有容器镜像打包起来，这是在 build 的过程中通过黑科技做到的，因为 build 过程会像 docker build 一样起长期的 Kubernetes 集群，而后咱们就晓得集群依赖了哪些容器镜像，最初把这些容器镜像打包。
2. 和 Kubernetes 一起打包，拿了一个 chart 它未必能装置胜利，比方应用了废除的 api 版本，然而做成镜像把 Kubnernetes 也包在一起了，只有 build 没问题，run 就没问题，这点和 docker 把操作系统 rootfs 打包在一起有殊途同归之妙。
3. 集成性，集群镜像更关注整个分布式应用集群整体打包，如把 prometheus ELK mysql 集群做成一个镜像服务与业务。

所以 sealer 与 helm 是协作关系，分工明确。

后续能够在 sealer 的官网镜像仓库中找到这些通用的集群镜像，间接应用即可。

SaaS 软件整体打包 / 交付 专有云离线交付

从分布式应用的视角看，通常从上往下，少则几个多则上百的组件，现有整体交付形式大多都是面向过程的，两头须要很多进行干涉的事，sealer 就能够把这些货色通通打包在一起进行一键交付。

可能你会问：咱们做个 tar.gz 再加个 ansible 脚本不也能一键化吗？答案是必定的。就和 docker 镜像呈现之前，大家也通过 tar.gz 交付一样，你会发现规范和技术的呈现解决了人与人之间的合作问题, 有了集群镜像就能够间接复用他人的成绩，也能制作好货色供他人应用。

专有云场景就非常适合应用 sealer，很多客户机房都是离线的，而集群镜像会把所有依赖打到镜像中，只有镜像制作得好，那么所有局点都能以雷同的形式进行一键交付，取得极佳的一致性体验。

在私有云上实际上述场景

sealer 自带对接私有云属性，很多状况下对接私有云会有更好的应用体验，比方装置集群时，只须要指定服务器数量和规格而不必关怀 IP，伸缩间接批改 Clusterfile 中定义的数字即可。

技术原理简介

写时复制

集群镜像的存储也是通过写时复制的形式实现的。这样做有两个益处：咱们能够把同一集群中不同的分布式软件打在不同层，以实现复用；还能够实现间接把集群镜像 push 到 docker 镜像仓库中。

容器镜像缓存

build 的过程中 sealer 是如何晓得待构建的集群镜像里有哪些容器镜像，以及怎么把容器镜像存储下来呢？其中有一些难点问题:

1. 如何晓得分布式软件中有哪些容器镜像？因为咱们须要把这些镜像缓存下来，不论是扫描用户的 yaml 文件还是用 helm template 之后扫描都是不完满的。首先不能确定用户的编排形式是什么，其次有些软件不把镜像地址写在编排文件中，而是通过本人的程序去拉起，无奈保障 build 胜利运行就肯定没问题。
2. 容器镜像是须要被存储到公有仓库中打包在集群镜像里，那容器镜像仓库地址势必和编排文件中写的不一样，特地是怎么保障用户 alwayPull 的时候还是可能在公有仓库中下载到镜像？

看待第一个问题，sealer 解决形式是：sealer build 的过程中和 Docker build 一样，会拉起一个长期的 Kubernetes 集群，并执行用户在 Kubefile 中定义的 apply 指令。

如上图所示，这样就能够保障用户依赖的所有镜像都被打包进去，无论用户应用什么样的编排形式。

第二个问题，咱们打包容器镜像到公有镜像仓库中，怎么应用这个公有镜像也是个难题，假如公有镜像仓库名为 localhost:5000，必定会和编排文件中写的不统一，对此咱们有两种形式解决：

• 第一种是 hack 和 docker，做了一个只有公有镜像仓库中有就间接从公有镜像中拉取，没有才去公网拉取镜像的能力。
• 第二种计划是无侵入 docke r 的 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。

原文链接
本文为阿里云原创内容，未经容许不得转载。