Kubernetes资源编排系列之二:Helm篇

作者 凌可(彭兰舒) 雪尧(郭耀星)

这是我们的《Kubernetes 资源编排系列》的第二篇——Helm 篇，在上篇（《Kubernetes 资源编排系列之一: Pod YAML 篇》，可从文末链接直达）我们见识到了 Pod YAML 的强大能力，在 k8s 的集群中，所见之处皆是 YAML。YAML 多了之后，大家就希望有一种方案能将海量的 YAML 管理起来。于是本篇我们来介绍一下 Helm。

Helm 是什么

Helm 是 Kubernetes 生态系统中的一个软件包管理工具，类似于 Ubuntu 中的apt、CentOS 中的 yum 等，它用于自动创建、打包、配置和部署应用程序和服务到 Kubernetes 集群。

Kubernetes 为用户提供了自动部署、扩展和管理容器化应用程序的能力，然而用户部署在 Kubernetes 集群上的应用可能会非常复杂，一个典型的应用（以 **SREWorks **为例）通常会有一系列对象进行内部交互来使得程序正常运转。

首先我们需要 Deployment 用于部署我们想要运行的 pods，例如 Mysql 数据库；StorageClass 用于动态分配存储卷；Persistent Volume（PV）用于储存数据库；Service 用于指定 pod 的访问策略使得外部可以访问 pod 的服务；Job 用于执行任务保证指定数量的 pods 部署成功……

在Helm诞生以前，配置每个对象都得依靠一个独立的YAML文件，之后再通过kubeclt apply逐个创建这些对象。倘若要对其中某些内容进行修改，就必须找到对应的yaml文件，然后在里面找到相应的属性；而要是想对其中一些组件进行升级，也得仔细编辑多个文件，以免出现错误或遗漏；当要删除这个应用程序时，同样得手动删除其对应的所有组件……

Kubernetes并非从“应用程序”的视角来管理集群里的各个组件，它仅仅是将用户提交的yaml保存在集群中并让它们各自运行，实际上它并不知晓用户声明的各个对象，像是Job、Service、StorageClass、Deployment等，是同一个应用程序下不同的构成部分。当应用变得复杂时，要记住变量的位置并手动执行操作，这既繁琐又复杂，而且会给多人协作开发应用增添难度。

在这样的基础上，Helm 应运而生，为开发人员提供了模块化的应用管理工具，降低了 Kubernetes 用户的工作量和工作复杂度。

Helm 是怎么做的?

Helm 将上述对象都看作一个程序包内的部分， 当我们想要对程序执行操作的时候，不需要告诉 helm 我们要对哪个对象进行变更，只用传入程序名称，Helm 会帮助我们对程序下的每个对象执行相应的操作。

这个包含了一组 yaml 文件的程序包，就叫做Helm Chart。

Chart 是一个描述 Kubernetes 相关资源的文件集合，它的格式如下：

└── sreworks-chart/
     ├── Chart.yaml    # 文件包含了对该chart的描述
     ├── values.yaml   # 文件包含了导入模版中的chart的默认值，会在用户执行helm install或helm upgrade时被覆盖
     ├── charts/       # 目录包含依赖的其他chart
     ├── templates/    # 目录包括了模板文件
     └── ...

开发时通常不会将 name 硬编码在资源中，用户可以通过插入发布名称来生成 name 字段。

所以我们的 job.yaml 就变为了：

apiVersion: v1
kind: Job
metadata:
   name: {{ .Release.Name }}-init-job

模板命令{{ .Release.Name }} 将发布名称注入了模板。值作为一个命名空间对象传给了模板，用点(.)分隔每个命名空间的元素。

在执行helm install命令时，模版渲染引擎会将括在{{ 和}} 之间的模版命令替换为 values.yaml 中定义的值或用户通过--set设置的值，并将渲染后的文件发送到templates目录中，然后收集结果并发送给 Kubernetes。

可以通过 helm 命令对 chart 执行相应的操作：

// 安装
$ helm install sreworks . -n sreworks、

// 升级
$ helm upgrade sreworks . -n sreworks

// 回滚
$ helm rollback sreworks -n sreworks

// 卸载
$ helm uninstall sreworks -n sreworks

还能用 Helm 创建自己的 charts，也可以从 Helm 仓库中下载。

社区的 Helm Chart 仓库位于 Artifact Hub，可以下载其他人上传的 chart 到本地使用，也可以将自己制作的 chart 上传到仓库中。同时 Helm 也支持创建并运行私有仓库，供个人和组织内部使用。

Helm 的优点

• 生命周期管理：可以实现对组件实例的查询、安装、卸载、升级、回滚
• 方便的命令行：对于简单变量，可以在部署的同时指定对应的参数，方便部署
• 插件和工具生态：作为 CNCF 项目，Helm 已经变成了 K8S 基础生态的一部分，各种各样的外部系统都会对它进行默认支持，CICD 工具集成方面有得天独厚的优势；同时用户能够从社区中获取丰富的专业知识和共享的 Chart 包
• 确保 Secret 安全性：一些敏感数据在 Kubernetes 中会存储为文本文件，作为 Helm 模版和值的一部分，而helm-secrets插件为关键信息提供秘密管理和保护，将相关值进行加密
• Chart 调试功能：Helm 提供了一些命令让用户在安装前测试资源的正确性，检查 Chart 是否正确生成，例如helm lint；helm install —dry-run — debug等

Helm 的缺点

• 应用定制受限于预置变量：Chart 是一种模板，Chart 的用户仅能通过对 values 的控制来定制组件的部署行为，模板中没有提供变量的位置，是无法在下游直接进行变更。
• YAML 文件的无序下发: 在 YAML 文件变多之后，尤其在 Operator-CRD 场景下，YAML 下发需要存在一定的先后顺序。helm 中利用一个叫 crd 目录来进行优先下发来避免问题。
• 应用安装状态感知：对于 Helm 而言，将所有 Chart 中的模版推到 Kubernetes 之后，它的 install 过程就结束了，它并不关心 yaml 中配置的各个组件在 Kubernetes 中是否能有效运行，而这恰恰是用户最关心的部分，因此使用 Helm 安装可能会出现用户无法感知的异常

SREWorks 对 Helm 的能力补充

部署 SREWorks 时的 Helm 安装进度反馈

SREWorks 平台自身的安装也是通过 Helm 包来实现的，常常会有一些 SREWorks 的用户以为 helm install 执行完就安装完了。事实上这个时候安装才刚刚开始。我们希望用户在这个过程中能够感知到具体的安装进度和异常反馈，于是我们在 helm install 执行完后提醒用户(该功能将于 v1.3 版本上线):

Please execute following command in terminal to trace the install progress:

kubectl logs job.batch/sreworks-progress-check -nsreworks -f

After install finished (5-10mins) open the following URL in your browser:

   http://xxxx/#/

   account: admin
   password: *****

在这个 sreworks-progress-check 的 job 中，我们实现了对 SREWorks 安装进度全跟踪。

我们编写了进度查询和错误诊断脚本，将其包装成 SREWorks 的一个 Job 和其他所有组件一起同步部署，这样用户就能在终端实时查看安装进度，并能在异常出现时及时进行排查。

进度查询：

错误诊断：

SREWorks 中的 Helm 组件状态统一管理

鉴于 Helm 并不跟踪各个组件的部署状态，在 SREWorks 中，我们复用 AppManager 已有的 Groovy 脚本托管能力，自己编写了一个小 Groovy 脚本，目的在于等待终态 + 获取数据。

代码如下：

getStatus(request) {
    def client = getKubeClient(kubeconfig from parameters)
    def service = client.services().inNamespace(namespace).withName(name).get()
    def response = new JSONObject()
    if (service.get("loadbalancer", "ingress", 0, "ip") not empty) {
        response.put("spec.metadata.annotations.vvpSlb", service.get("loadbalancer", "ingress", 0, "ip"))
        return Status.builder().response(response).status("SUCCESS").build();
    } else {
        return Status.builder().status("RUNNING").build();
    }
}

上述流程完成了 Helm 的安装、终态等待及数据获取。

上述 getStatus() 函数除了部署过程会刷 (5s/次)；部署完之后也会一直刷，不过频率逐步降低到 5min/次。作为状态感知的数据来源。

SREWorks 中的 Helm 组件顺序部署

前面也提到过 Helm 的 YAML 文件无序下发针对大型工程而言，会有一定的影响。SREWorks 的 Appmanager 基于 OAM 模型实现了 workflow 能力，能够支持多个 Helm 组件按照 DAG 图的顺序部署。

SREWorks 应用 Helm 组件实践

Tips: 虽然 Helm 官方将自身托管的 Chart 对应的包称为应用 (Application)，但在一个真实的复杂应用 (Appliation) 下，Helm Chart 更像是应用 (Application) 中的组件 (Component)。故在 SREWorks 中将 Helm 托管的 Chart 归为组件 (Component)。

点击进入 SREWorks 的“运维开发”应用，点击运维开发-后端开发-Helm 组件就能看到 Helm 组件列表，图中所示均为安装在本地的 Helm 组件。

点击上图中“新增 Helm 组件的按钮”，就可以将 Helm 组件添加到应用中，而组件来源可以是社区仓库也可以是代码仓库。针对社区中的开源软件，可以直接使用社区仓库中持续更新维护的 helm 源。

只要在页面上点击 Helm 组件添加，SREWorks-Appmanager 就会根据这些信息会自动生成标准的 OAM 模型 YAML 文件。用户无需关心 helm install 的细节，只需要在页面上点击部署就可以实现一个或多个 Helm 组件的部署。

部署完成后可在运维应用-应用部署的页面查看部署记录。同时在应用实例中也可以看到这个应用。

SREWorks 也在公共市场中添加了几个开源的应用组件供用户使用（持续更新中～），同时也支持用户将自己制作或部署的 Helm 组件上传到本地市场中。

总结

在 SREWorks(Appmanager)的应用体系中，对于承载组件 (Component) 这个概念而言，Helm 是再合适不过的工具。K8S YAML 或 Kustomize(下一篇会提到) 会让使用者沉浸于过多的细节中难以自拔，而 Helm 非常明确自己的选择：把复杂交给开发者，把简单交给使用者。Helm 的自定义参数可以让开发者把 Chart 包装为一个黑盒，并明确这个黑盒可以接受什么参数。使用者不用关心黑盒里面是什么，只需要调整这些开发者暴露出来的参数来满足自己的需求即可。开发者、使用者的边界在组织中可以被正常映射为研发团队和 SRE 团队，在认知和共识层面无需进一步投入成本。

后续文章我们会分享更多的 Kubernetes 组件和应用管理工具，均会发布在我们的公众号“阿里智能运维”上，请大家持续关注～也欢迎大家在公众号后台留言想了解的内容和感兴趣的相关话题，与 SREWorks 团队进行交流。