Sealer 0.9 ：帮助集群和分布式应用实现 Build ShareRun

Posted 2023-02-23 阿里云云栖号

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Sealer 0.9 ：帮助集群和分布式应用实现 Build ShareRun相关的知识，希望对你有一定的参考价值。

新春之际，很高兴在此时宣布 Sealer[1] 0.9 版本的正式发布。Sealer 是一款致力于探索面向分布式应用的快速打包、交付和运行的解决方案。2021 年5月 Sealer 项目正式开源；短短一年时间，Sealer 在 2022 年 4 月成为 CNCF Sandbox 项目。

Sealer 0.9 版本中，其在核心定位上由专注 “集群维度的 Build，Share，Run” 升级为 “以集群为基础，以应用为中心，帮助集群和分布式应用实现 Build, Share，Run”，并重点增强了对应用的支持能力。

版本详解

增强对应用的支持

应用与集群解耦

Docker Image 很好的解决了单机应用的打包交付问题，而 Sealer Image[2] 尝试在集群维度，解决类 Kubernetes 集群以及分布式应用的打包交付问题。Sealer Image 基于包含内容将 Sealer Image 分为集群镜像和应用镜像。其中：

集群镜像，表示一个镜像包含 cluster runtime，如 Kubernetes、K0S、K3S 等。Run 阶段既会安装集群也会安装应用（如果包含了应用）
应用镜像，表示一个镜像未包含 cluster runtime，其需要基于已有的集群进行安装。

Kubefile 支持 LABEL & KUBEVERSION 指令

Kubefile 中 LABEL 指令类似 Dockerfile LABEL 指令，允许用户针对 `Sealer Image` 指定一些元数据信息，这些元数据信息在构建完成后可通过 sealer inspect 命令查看。

其中，Sealer 官方保留以 *http://sealer.io/ 为前缀的 label key，如：
针对集群镜像，通过 LABEL 可声明集群镜像支持的能力列表等信息

http://cluster.alpha.sealer.io/cluster-runtime-type，支持的集群类型，如 kubernetes, k0s, k3s 等
http://cluster.alpha.sealer.io/cluster-runtime-version，支持的集群 runtime 的版本，如 kubernetes 版本
http://cluster.alpha.sealer.io/container-runtime-type，支持的 container runtime 类型，如 docker，containerd 等
http://cluster.alpha.sealer.io/container-runtime-version，支持的 container runtime 版本，如 docker 版本
http://cluster.alpha.sealer.io/kube-cni，支持的 CNI 列表，如 calico，flannel 等
http://cluster.alpha.sealer.io/kube-csi，支持的 CSI 列表，如 alibaba-cloud-csi-driver 等

针对应用镜像，通过 LABEL 可声明应用镜像兼容的 kube runtime 版本等信息，通过声明解耦集群镜像

http://app.alpha.sealer.io/supported-kube-version，应用镜像支持的 kube runtime 版本，其值定义 Semantic Versioning 2.0.0[3]。另外，Kubefile 中也可通过 KUBEVERSION 指令快捷定义该 label 的值。

集群镜像 Kubefile：

应用镜像 Kubefile：

Build 支持打标镜像类型

为了让使用者在获取到一个镜像后，能够清晰的知道一个镜像包含的内容以及行为。在 build image 阶段，Sealer 可以通过 sealer build --type kube-installer | app-installer 为构建出来的 Sealer Image 打标。

kube-installer，集群镜像。

2.app-installer，应用镜像。

Run 简简单单运行应用镜像

针对应用镜像（sealer build --type app-installer），部署在基于 Sealer 集群镜像部署的集群内，仅需简单单单一条命令即可，用户也不需要再关心集群节点信息等。

TODO: 针对应用镜像声明支持的 KUBEVERSION，运行应用镜像时验证此版本约束

Kubefile 让应用定义更简单

Kubefile 新增加APP 指令，其允许用户定义一个 APP 虚拟对象，通过 CNI、CSI 指令分别支持 CNI，CSI 插件的管理，通过 APPCMDS 指令为 APP 指定安装命令，并可以通过 LAUNCH 指令，以 APP 对象为维度选择启动对象。

APP 指令

APP 指令格式 APP APP_NAME scheme:path1 scheme:path2，其中：

APP 指令在 Kubefile 范围内可定义多次
APP_NAME 在 Sealer Image 范围内需保证唯一
schema 目前支持如下格式：
1. local://path_rel_2_build_context (build context 中的文件，文件路径为基于 build context 的相对路径）
2. http(s)://example.yaml （http(s) 远程地址，会在 build 节点自动下载）
path 的目录/文件类型目前支持如下类型：
1. .sh，shell 脚本
2. .yaml | .yml，kubernetes YAML 文件
3. Helm Chart 目录

CNI/CSI 指令

PS: CSI 与 CNI 基本类似，此处不再赘述

CNI 指令格式 CNI CNI_NAME scheme:path1 scheme:path2，通过 CNI 指令可以以一种更规范的方式定义/操作 Kubernetes CNI 插件，其中：

CNI 指令本质上是指定了 CNI 网络插件类型的 APP，所有特性与 APP 指令相同
CNI 指令相比 APP 指令，会自动生成 label key http://cluster.alpha.sealer.io/kube-cni 声明镜像支持的 CNI 网络插件列表，例如: "http://cluster.alpha.sealer.io/kube-cni": ["calico", "flannel"]

APPCMDS 指令

APPCMDS 指令格式 APPCMDS APP_NAME ["executable","param1","param2"]，其中:

类似 Dockerfile CMD 指令，但其作用域为 APP 维度
针对同一个 APP_NAME，如果有多个 APPCMDS 被指定，仅最后一个生效

LAUNCH 指令

LAUNCH 指令格式 LAUNCH ["APP_NAME_1", "APP_NAME_2"]，其中：

LAUNCH 指令在 Kubefile 范围内仅可定义一份
如果 APPCMDS 未指定，则 LAUNCH 指令会尝试自动解析文件类型，并自动生成执行行为
FROM 镜像中包含的 LAUCH 指令不生效，仅最后一个 LAUNCH 指令生效（例如：对于子镜像，如果需要，需要在子镜像中重新填写父镜像中的 LAUNCH 指令）
APP_NAME 可以是 Sealer Image 范围内的，允许指定 FROM 镜像中声明的 APP_NAME

Kubefile 预览

集群镜像 Kubefile：

应用镜像 Kubefile：

Clusterfile 扩展支持应用配置

Clusterfile 中，同样可以以 APP 为维度进行运行前的配置变更。

通过 ClusterSpec.appNames 覆盖 Kubefile 中的 LAUNCH 指令值，如下所示，Kubefile 中包含了 nginx，mysql 两个 APP，在 appNames 中只需一条简单的配置 appNames: [ "nginx" ]，即可变更运行镜像的启动行为为只运行 nginx 这个 APP。
通过 Application Config，同样可以非常便捷的覆盖 Kubefile 中针对 APP 指定的 APPCMDS 内容，在运行态自定义启动命令。（同时社区也正在推进支持 APP 包含的文件的修改能力，详情可参考 #1969[4] ）

其他值得关注点

镜像引擎升级，Sealer Image 拥抱 OCI 标准

本着追求开放生态的初心，在开放性和标准划上 Sealer 社区也尝试更进一步。基于轻量化 buildah[5] 升级 Sealer 镜像引擎，全面兼容 OCI 标准。

基于标准的 K8S webhook 能力实现 image policy，不再有 hack

私有化交付场景下，如何将依赖的所有容器镜像，在用户无感知的情况下带入到私有化环境中并使用。

之前版本中， Sealer 社区尝试通过定制化 docker 配置项，在 docker daemon 层面实现镜像优先从内置镜像仓库拉取，内置镜像仓库不存在则从远程仓库拉取。

上述方案确实很好的解决了镜像代理的问题，但其有一定的局限性：

不兼容用户已有 docker，要求环境内不存在或者卸载 docker
针对自定义 Docker 需求，同样需要进行如上的定制化配置
上述方案仅针对 Docker Engine 有效，对 containerd 等其他 container runtime 需要另做处理

经过探索，Sealer 社区讨论后考虑基于社区标准的 kubernetes 扩展机制来解决上述问题。经过调研， Kyverno[6]是一款 Kubernetes policy 引擎，其可以以一种非常简单的配置方式支持对 Kubernetes 资源进行校验和修改能力，同时其针对 K0s，K3s 等 cluster runtime 同样适用。

未来规划

接下来，Sealer 将会继续秉持以集群为基础，以应用为中心，继续在打包、交付和运行的道路上持续探索。

以应用为中心，构建完善的分布式应用协作生态。
1. 丰富应用模型，支持应用基于声明能力一键化部署
2. 覆盖应用全生命周期，甚至运维监控能力
3. 扩大生态，如支持更多 APP 类型，如 helm chart/ kube resource/kustomize/shell/ OAM 应用等
4. 打造社区版 Sealer Image Hub，为基于 Sealer Image 的协作提供平台
以集群为基础，构建稳定易用的集群交付能力。
1. 一键支撑大规模集群，解决大规模集群的安装部署、镜像分发等问题
2. 丰富 container runtime，cluster runtime 支持生态
3. 目前社区同学已经正在推进 containerd container runtime 和 k0s、k3s cluster runtime 的支持
4. 丰富集群运行时运维工具箱，例如证书签发、健康检查、OS 审计等
5. 支持集群镜像的升级能力，帮助用户可以持续使用最新最稳定的集群镜像