作者：凌可（彭兰舒）、雪尧（郭耀星）
这是我们的《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也支持创建并运行私有仓库，供个人和组织内部使用。
