乐趣区

关于阿里云:Sealer-09-帮助集群和分布式应用实现-Build-ShareRun

作者:sealer 社区

新春之际,很快乐在此时发表 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 官网保留以 *sealer.io/ 为前缀的 label key,如:
针对集群镜像,通过 LABEL 可申明集群镜像反对的能力列表等信息

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

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

  • app.alpha.sealer.io/supported-kube-version,利用镜像反对的 kube runtime 版本,其值定义 Semantic Versioning 2.0.0 [ 3] 。另外,Kubefile 中也可通过  KUBEVERSION 指令快捷定义该 label 的值。

集群镜像 Kubefile:

FROM sealerio/kubernetes:v1.22.15

# Add some metadata to an image just like `Dockerfile LABEL instruction`.
# An image can have more than one label. You can specify multiple labels on a single line.
# 
# NOTE: 
# 1. In general, a base image should declare supported cluster runtimes, container runtimes, etc.
# 2. Sealer reserves all label keys prefixed with `sealer.io`.
# 3. All labels will be inherited by child image.
# LABEL <key>=<value> <key>=<value> <key>=<value> ...
# LABEL <key>=<value> \
#       <key>=<value> \
#       <key>=<value> ...
LABEL "cluster.alpha.sealer.io/cluster-runtime-version"="v1.22.15"
# such as kubernetes, k0s, k3s, etc
LABEL "cluster.alpha.sealer.io/cluster-runtime-type"="kubernetes" 
LABEL "cluster.alpha.sealer.io/container-runtime-type"="docker"
LABEL "cluster.alpha.sealer.io/container-runtime-version"="20.10.14"
......

利用镜像 Kubefile:

FROM scratch

# A SemVer range of compatible Kubernetes versions by the applications.
# If there are multiple apps in the `Kubefile`, you should take the intersection of the cluster versions they support
# The label `app.alpha.sealer.io/supported-kube-version` will be gernetated with `KUBEVERSION`.
# For a detailed explanation of supported semver constraints see [Masterminds/semver](https://github.com/Masterminds/semver).
KUBEVERSION 1.22 - 1.24

LABEL "created-by"="sealer.io"
......
Build 反对打标镜像类型

为了让使用者在获取到一个镜像后,可能清晰的晓得一个镜像蕴含的内容以及行为。在  build image 阶段,Sealer 能够通过 sealer build –type kube-installer | app-installer 为构建进去的 Sealer Image 打标。

  1. kube-installer,集群镜像。
  1. app-installer,利用镜像。
Run 简简单单运行利用镜像

针对利用镜像(sealer build –type app-installer),部署在基于 Sealer 集群镜像部署的集群内,仅需简略单单一条命令即可,用户也不须要再关怀集群节点信息等。

TODO: 针对利用镜像申明反对的 KUBEVERSION,运行利用镜像时验证此版本束缚

sealer run {{.appImageName}}

Kubefile 让利用定义更简略

Kubefile 新减少 APP 指令,其容许用户定义一个 APP 虚构对象,通过 CNI、CSI 指令别离反对 CNI,CSI 插件的治理,通过 APPCMDS 指令为 APP 指定装置命令,并能够通过 LAUNCH 指令,以 APP 对象为维度抉择启动对象。

APP 指令

APP 指令格局 APP APP_NAME scheme:path1 scheme:path2,其中:

  1. APP 指令在 Kubefile 范畴内可定义屡次
  2. APP_NAME 在 Sealer Image 范畴内需保障惟一
  3. schema 目前反对如下格局:

<!—->

    1. local://path_rel_2_build_context (build context 中的文件,文件门路为基于 build context 的相对路径)
    2. http(s)://example.yaml(http(s) 近程地址,会在 build 节点主动下载)

<!—->

  1. 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 插件,其中:

  1. CNI 指令实质上是指定了 CNI 网络插件类型的 APP,所有个性与 APP 指令雷同
  2. CNI 指令相比 APP 指令,会主动生成 label key cluster.alpha.sealer.io/kube-cni 申明镜像反对的 CNI 网络插件列表,例如: “cluster.alpha.sealer.io/kube-cni”: [“calico”, “flannel”]
APPCMDS 指令

APPCMDS 指令格局 APPCMDS APP_NAME [“executable”,”param1″,”param2″],其中:

  1. 相似 Dockerfile CMD 指令,但其作用域为 APP 维度
  2. 针对同一个 APP_NAME,如果有多个 APPCMDS 被指定,仅最初一个失效
LAUNCH 指令

LAUNCH 指令格局 LAUNCH [“APP_NAME_1”, “APP_NAME_2”],其中:

  1. LAUNCH 指令在 Kubefile 范畴内仅可定义一份
  2. 如果 APPCMDS 未指定,则 LAUNCH 指令会尝试主动解析文件类型,并主动生成执行行为
  3. FROM 镜像中蕴含的 LAUCH 指令不失效,仅最初一个 LAUNCH 指令失效(例如:对于子镜像,如果须要,须要在子镜像中从新填写父镜像中的  LAUNCH 指令)
  4. APP_NAME 能够是 Sealer Image 范畴内的,容许指定 FROM 镜像中申明的 APP_NAME
Kubefile 预览

集群镜像 Kubefile:

FROM sealerio/kubernetes:v1.22.15

# Override or provide CNI plugins, the syntax is same with `APP`. In fact, we can think of CNI as a special kind of `APP`.
# And multiple `CNI` definitions can be specified. If the name is the same, the last one takes precedence.
# In addition, the CNI plugin is not only an app, but also reflected in the label `cluster.alpha.sealer.io/kube-cni`.
CNI calico local://install-calico.sh
CNI calico local://install-calico-new.sh
CNI flannel local://flannel.yaml

# Override or provide CRI plugins just like `CNI`.
# In addition, the CNI plugin is not only an app, but also reflected in the label `cluster.alpha.sealer.io/kube-csi`.
CSI alibaba-c

利用镜像 Kubefile:

FROM scratch

# A SemVer range of compatible Kubernetes versions by the applications.
# If there are multiple apps in the `Kubefile`, you should take the intersection of the cluster versions they support
# NOTE: This value will not be inherited.
# The label `app.alpha.sealer.io/supported-kube-version` will be gernetated with `KUBEVERSION`.
# For a detailed explanation of supported semver constraints see [Masterminds/semver](https://github.com/Masterminds/semver).
KUBEVERSION 1.22 - 1.24

# add redis app
# ["kubectl apply -f redis.yaml"] will be executed
APP redis local://redis.yaml

# add nginx app
# ["kubectl apply -f nginx.yaml -n nginx-namespace"] will be executed
APP nginx local://nginx.yaml
# `APPCMDS` specify the cmds for a specified app and the context is the dir of specified app.
# The `APPCMDS` instruction format: ["executable","param1","param2"]
# If there are more than one `APPCMDS` for a `APP` then only the last `APPCMDS` will take effect.
APPCMDS nginx ["kubectl apply -f nginx.yaml -n nginx-namespace"]

# add mysql app
# ["helm install mysql . -f values.yaml --set key=value"] will be executed
APP mysql local://charts/mysql/ local://values.yaml
# `APPCMDS` must be specified when the app has multiple files
APPCMDS mysql ["helm install mysql .",  "-f values.yaml",  "--set key=value"]

LABEL <key>=<value> <key>=<value> <key>=<value> ...
LABEL "created-by"="sealer.io"

# The following operation will be executed:
# ["kubectl apply -f nginx.yaml -n nginx-namespace", "helm install mysql . -f values.yaml --set key=value"]
LAUNCH ["nginx", "mysql"]

Clusterfile 扩大反对利用配置

Clusterfile 中,同样能够以 APP 为维度进行运行前的配置变更。

  1. 通过 ClusterSpec.appNames 笼罩 Kubefile 中的 LAUNCH 指令值,如下所示,Kubefile 中蕴含了 nginx,mysql 两个 APP,在 appNames 中只需一条简略的配置 appNames: [“nginx”],即可变更运行镜像的启动行为为只运行 nginx 这个 APP。
  2. 通过 Application Config,同样能够十分便捷的笼罩 Kubefile 中针对 APP 指定的  APPCMDS 内容,在运行态自定义启动命令。(同时社区也正在推动反对 APP 蕴含的文件的批改能力,详情可参考  #1969 [ 4]
apiVersion: sealer.cloud/v2
kind: Cluster
metadata:
  name: my-cluster
spec:
  image: myimage-with-nginx-mysql:v1
  appNames: ["nginx"]
  ......
---
apiVersion: sealer.io/v2
kind: Application
metadata:
  name: my-apps
spec:
    configs:
    - name: app1
      launch:
        cmds:
        - kubectl apply -f ns.yaml
        - kubectl apply -f nginx.yaml -n namespace
    - name: app2
      launch:
        cmds:
        - helm install my-nginx bitnami/nginx
    - name: app3
      launch:
        cmds:
        - bash nginx.sh

其余值得关注点

镜像引擎降级,Sealer Image 拥抱 OCI 规范

本着谋求凋谢生态的初心,在开放性和规范划上 Sealer 社区也尝试更进一步。基于轻量化 buildah [ 5] 降级 Sealer 镜像引擎,全面兼容 OCI 规范。

基于规范的 K8S webhook 能力实现 image policy,不再有 hack

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

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

//daemon.json 定义 
{
  "mirror-registries":[
      {
        "domain": "*",
        "mirrors": ["http://sea.hub:5000", "https://mirror.test2.com"]
      }
  ],
  "insecure-registries": ["sea.hub:5000", "mirror.test1.com"]
}

上述计划的确很好的解决了镜像代理的问题,但其有肯定的局限性:

  1. 不兼容用户已有 docker,要求环境内不存在或者卸载 docker
  2. 针对自定义 Docker 需要,同样须要进行如上的定制化配置
  3. 上述计划仅针对 Docker Engine 无效,对 containerd 等其余 container runtime 须要另做解决

通过摸索,Sealer 社区探讨后思考基于社区规范的 kubernetes  扩大机制来解决上述问题。通过调研,Kyverno [ 6] 是一款 Kubernetes policy 引擎,其能够以一种非常简单的配置形式反对对 Kubernetes 资源进行校验和批改能力,同时其针对 K0s,K3s 等 cluster runtime 同样实用。

将来布局

接下来,Sealer 将会持续秉持 以集群为根底,以利用为核心,持续在打包、交付和运行的路线上继续摸索。

  1. 以利用为核心,构建欠缺的分布式应用合作生态。

<!—->

    1. 丰盛利用模型,反对利用基于申明能力一键化部署
    2. 笼罩利用全生命周期,甚至运维监控能力
    3. 扩充生态,如反对更多 APP 类型,如 helm chart/ kube resource/kustomize/shell/ OAM 利用等
    4. 打造社区版 Sealer Image Hub,为基于 Sealer Image 的合作提供平台

<!—->

  1. 以集群为根底,构建稳固易用的集群交付能力。

<!—->

    1. 一键撑持大规模集群,解决大规模集群的装置部署、镜像散发等问题
    2. 丰盛 container runtime,cluster runtime 反对生态
    3. 目前社区同学曾经正在推动 containerd container runtime 和 k0s、k3s cluster runtime 的反对
    4. 丰盛集群运行时运维工具箱,例如证书签发、健康检查、OS 审计等
    5. 反对集群镜像的降级能力,帮忙用户能够继续应用最新最稳固的集群镜像

更多举荐

CNStack 社区版:

https://github.com/alibaba/CN…

ACK Distro:

https://github.com/AliyunCont…

欢送钉钉扫描下方二维码或搜寻群号 34619594 退出 CNCF sealer 社区交换钉群!

相干材料

[1] Sealer:

https://github.com/sealerio/s…

[2] Sealer Image:

http://sealer.cool/docs/conce…

[3] Semantic Versioning 2.0.0:

https://github.com/Mastermind…

[4] #1969

https://github.com/sealerio/s…

[5] Buildah:

https://github.com/containers…

[6] Kyverno:

https://github.com/kyverno/ky…

点击此处查看 Sealer 官网文档

退出移动版