共计 4929 个字符，预计需要花费 13 分钟才能阅读完成。
作者 凌可(彭兰舒) 雪尧(郭耀星)
这是咱们的《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 团队进行交换。