引言

helm 是 k8s 的包管理工具，使用 helm，可以使用更为简化和系统化的方式对 k8s 应用进行部署、升级。

helm 是 CNCF 已毕业的项目，社区也是相当活跃的，在 https://artifacthub.io/ 上，能找到很多现成的 helm chart，稍作修改就能用到生产环境中，非常方便。

本文会介绍 helm 的核心概念，并用一个例子帮助大家更直观的认识 helm，大家可以跟着这个例子操作一遍，相信对理解 helm 会有非常大的作用。（教程地址：https://github.com/zkf1317/cloud-native-tutorial ）

什么是 helm

初识 helm

helm 在希腊语中的意思是：舵；驾驶盘。据说是 helm 创始人 mutt butcher 翻遍了航海手册找出来的，目的是为了找一个和 kubernetes 主题相匹配的词语。

官网地址：https://helm.sh/

官方给出的解释是：Helm is the best way to find, share, and use software built for Kubernetes. 意思是 helm 是 kubernetes 中查找、分享、构建应用的最佳方式。

这种说法当然不算夸张，Helm 其实是一个 Kubernetes 应用的包管理工具，用来管理 chart（一种预先配置好的安装包资源），有点类似于 Ubuntu 的 APT 和 CentOS 中的 YUM。因此，helm 的出现解决了 k8s 应用管理能力缺失的问题。

另外 helm 也是 dev 和 ops 的桥梁，运维人员在使用 helm 的时候，一方面不需要理解大量在 chart 中的各种 k8s 元素，只需要配置少量的环境变量即可安装；另一方面，helm 也给初级运维人员提供了学习的机会，他们可以在 chart 中学习并理解各种 k8s 元素，从而能够更快的掌握 k8s。

下面列举了 helm 的一些关键信息

• 2019 年 11 月 13 日，Helm 3 发布；

• 2020 年 4 月 30 日，从 CNCF 中毕业；

• 目前 github 上接近有 1.9w 个 Star；

• 最新版本：3.5.0；

• 主要作者：Mutt Butcher，目前在 Microsoft，主要关注 DevOps 领域。

helm 与 apt 对比

在我们接触一个新事物的时候，最好的学习方式就是和我们熟悉的事务来做类比，能够帮助我们快速的掌握其中的核心概念。

由于 Mutt Butcher 在设计 helm 的时候，大量参考了 apt 和 homebrew 的设计，这里我们用 apt 来做对比，帮助大家更好的理解 helm。

从下表中可以看到，helm 和 apt 之间概念的对比，相信熟悉 apt 的同学能够很快的对 helm 有一个初步的认识。

helm 总览

对 helm 有了一个初步的印象之后，我们来对 helm 做一个总览，包括 helm 的的核心概念、运行流程、常用命令、chart 做一个概要性的了解，这样的话，对我们后续深入 helm 的学习和实践起一个纲领的作业，避免只见树木、不见森林。

helm 三大概念

• chart：chart 就是 helm package，包含了一个 k8s app 应用运行起来的所有要素，比如 service, deployment, configmap, serviceaccount, rbac, 等，这些要素都是以 template 文件的形式存在，再结合 values 文件，最终渲染出能够被 k8s 执行的 yaml 文件；

• repository：仓库是 charts 的集合，方便进行分享和分发。下面是官网仓库和阿里云仓库的地址，大家可以进去看看，感受一下；

• https://artifacthub.io/
  

• https://developer.aliyun.com/hub
  

• release：release 是 helm chart 在 kubernetes 的一个运行实例，你可以用不同的 release name 多次安装同一个 chart，比如：当集群中需要多个 redis 实例，你可以使用不同的配置文件安装 redis chart。

helm 运行流程

下面这张图我建议大家多看几遍，可以说掌握了这张图，就掌握了 helm 的核心。

从下图可以看到，helm 的核心运行流程分为以下几步：

• 从 chart 仓库中获取 chart；

• 使用者配置自己的 values 文件，根据自己的运行环境对 values 进行修改；

• 默认 values 文件和使用者 values 文件会进行一个 merge，形成最终的 values 文件；

• 使用最终的 values 文件，渲染 chart 的 template，形成可以被 kubernetes 执行的 yaml；

• 调用 kube apply 提交 yaml 到 kubernetes

在这里，需要注意 chart 开发者和使用者的界限，正是由于在跨越这个界限的时候，从需要理解大量的配置到只需要理解少量的配置，使得 ops 的工作变得简便，这也是 helm 核心的设计哲学。看完整个文章，即使你什么都没记住，只记住了这张图，你也会有很大的收获了。

helm 常用命令

在 helm 的时候，你可以使用第三方开发的 chart，也可以自己开发 chart，以下是两种情况下使用的常见命令。更为详细的命令，可以安装好 helm 之后，使用 helm help 来查看，或查看官方文档。

使用第三方开发的 chart

部署前

• repo: add, list, remove, update, and index chart repositories

• search: search for a keyword in charts

部署后

• install: install a chart

• list: list releases

• status: display the status of the named release

• upgrade: upgrade a release

• rollback: roll back a release to a previous revision

• uninstall: uninstall a release

自己开发 chart

• lint: examine a chart for possible issues

• package: package a chart directory into a chart archive

• push: push helm chart to chartmuseum

• chart push: push helm chart to OCI repository

chart

chart 可以说是 helm 里面最重要的概念了，关于 chart 也有很多内容需要掌握，在这里做一个列举。

• chart 开发：主要是指利用模板技术开发一个 chart，会在后面做详细介绍；

• chart hooks：在 chart 的生命周期中，提供一些 hooks，方便进行一些前置或后置操作。

• 在 chart 安装前，创建应用需要的 Secret

• 在 chart 安装前，备份数据库

• 在 chart 卸载后，做一些清理工作

• chart test：当你 install 了一个 chart 后，如何知道这个 release 是否运行正常呢？chart test 提供了一种测试的方式，来验证你的应用是否正常运行，比如：

• 校验 mysql 应用能够正常连接并接受请求；

• 校验 services 能够正常做 load balance；

• library chart：一种以 library 形式存在的 chart，可以在 application chart 之间进行共享避免重复逻辑；类似于编程语言中的 public library；

• chart 校验：基于 PKI、GnuPG 等技术，对 helm package 进行签名，保证传输或发布过程中的安全性；

• OCI（Open Container Initiative，容器发型规范）支持：helm 3 引入（EXPERIMENTAL），能够将 chart 推送到支持 OCI 的仓库中，比如 harbor, nexus，等，比如，将 chart 保存到 harbor 中：

• 保存 chart：helm chart save kubeedge/ some-harbor-repo/kubeedge-cloud-chart:1.0.0

• 登录 repo：helm registry login https://some-harbor-repo

• 推送 chart：helm chart push some-harbor-repo/kubeedge-cloud-chart:1.0.0

• 高级特性

• post rendering: 提供在 helm install 之前对 manifests 进行操作、配置的一种机制；一般结合 kustomize 使用。比如：

• 在 install 时插入 sidecar，从而为 deployment 增加功能

• 不修改原 chart 的情况下，更改 manifests 的配置

这可能不是非常好理解，这里举一个例子，假设我需要对一个第三方的 chart 做少量的修改，以满足我的部署要求，那么我可以 fork 一份这个 chart，然后在上面做修改，但是这样我需要一些额外的维护工作，当这个 chart 升级之后，我还需要做 merge 的工作，十分不便。

因此 post rendering 提供了一种机制，你只需要使用 post rendering+kustomize 编写的一个脚本，就可以在 install 前，对原始 chart 的内容做一些定制化的修改，避免了额外的维护工作。如下图所示。（kustomize 是一个开源的配置工具，可以方便的对现有的 k8s app 配置做一些定制化的修改，官网地址：https://kustomize.io/）

• go sdk：helm 提供了 golang sdk，方便在 go 语言中使用；

• storage backend：指定 release 信息的存储类型，默认是 secret；可以指定 configmap、secret 和 postgreSQL；下图显示 helm 的版本信息存放在 secret 中的情况。

• helm plugin：支持以插件的形式拓展 helm 的功能。

helm demo

下面我们一起用一个 demo 来对 helm 有一个更为直观的了解。在这个 demo 中，我们的目标是部署一个 redis 集群，包括以下几个步骤：

• 安装 helm

• 使用 helm install 单节点 redis

• 使用 helm upgrade 升级到 master-slave

• 使用 helm rollback，回滚到单节点模式

步骤 1：安装 helm（通过 apt）

以下是通过 apt 安装 helm 的命令，其他的安装方式可参考官网：

curl https://baltocdn.com/helm/signing.asc | sudo apt-key add – sudo apt-get install apt-transport-https --yes echo "deb https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list sudo apt-get update sudo apt-get install helm=3.4.2-1

步骤 2：添加仓库并找到 redis chart

• 添加仓库：helm repo add stable https://charts.helm.sh/stable

• 查看已经添加的仓库：helm repo list

• 搜索仓库有哪些 chart：helm search repo stable

• 更新仓库列表到本地：helm repo update

• 搜索 redis：helm search repo redis

• 查看 redis chart 详情：helm show chart stable/redis

• 查看 redis values（values：相当于 chart 的配置文件）：helm show values stable/redis

步骤 3：install/upgrade/rollback/uninstall

• 建立单 master 的配置文件，名为 only-master.values

## Cluster settings  cluster:    enabled: false
## Redis pod Security Context  securityContext:    enabled: false
## Use password authenticationusePassword: true## Redis password (both master and slave)password: "admin"
## Redis Master parametersmaster:  persistence:    enabled: false

然后--dry-run 一下，看看生成出来的 yaml 文件是否存在问题：

helm install redis-demo stable/redis -f ./only-master.values --dry-run

如果没有问题，则进行实际的安装：

helm install redis-demo stable/redis -f ./only-master.values

安装成功之后，可以登录 redis 进行操作，做进一步的校验：

redis-cli -h kubectl get svc redis-demo-master -o=jsonpath="{.spec.clusterIP}" -a adminset name zhangsanget nameinfo replication：可以看到这时候没有slave连接

• 建立 master-slave 配置文件，名为 master-slave.values

## Cluster settingscluster:  enabled: true  slaveCount: 1
securityContext:  enabled: false
## Use password authenticationusePassword: truepassword: "admin"
## Mount secrets as files instead of environment variablesusePasswordFile: false
## Redis Master parametersmaster:  persistence:    enabled: false
## Redis Slave propertiesslave:  persistence:    enabled: false

--dry-run 一下，看看生成出来的 yaml 文件是否存在问题；由于在系统中已经有 redis-demo 的 release，因此使用 upgrade 来进行升级：

helm upgrade redis-demo stable/redis -f ./master-slave.values --dry-runhelm upgrade redis-demo stable/redis -f ./master-slave.values

检查 slave 是否安装成功，以及是否同步成功

redis-cli -h kubectl get svc redis-demo-slave -o=jsonpath="{.spec.clusterIP}" -a adminget name

• 最后，回滚至单 master 模式

• 查看部署历史：helm history redis-demo

• 回滚到对应的单 master 版本：helm rollback redis-demo REVISION

• 再连接 slave 已经不成功了：

redis-cli -h kubectl get svc redis-demo-slave -o=jsonpath="{.spec.clusterIP}" -a admin

• 只有 master 能连接

redis-cli -h kubectl get svc redis-demo-master -o=jsonpath="{.spec.clusterIP}" -a admin# 输入命令测试一下get age

• 卸载 redis-demo

helm uninstall redis-demo

chart 详解

总体结构

下图是 wordpress 的 helm chart 目录结构，每个元素的解释如下：

• Chart.yaml: chart 的信息，包括 chart 的版本信息、描述信息、依赖关系，等

• LICENSE: (可选)chart 的 LICENSE 信息

• README.md: (可选)chart 的说明文件

• values.yaml: chart 的默认配置信息

• values.schema.json: (可选) values 配置信息的元信息（字段类型、字段描述、字段之间的依赖等），格式 json

• charts: 依赖的其他 chart

• crds: Custom Resource Definitions

• templates: 部署模板，结合 values.yaml 会渲染出 kubernetes yaml 文件

• templates/NOTES.txt: (可选)安装说明

Chart.yaml

Chart.yaml 相当于 chart 的说明书，说明了这个 chart 的功能、版本、依赖关系、关键字等信息。

下图是 redis 的 Chart.yaml：

• apiVersion: chart api version, 目前 helm 3 固定为 v2

• name: chart 名字

• description: chart 描述

• type:

• application: 可部署的 chart

• library: 不可部署，可在不同 chart 间共享公用逻辑

• version: chart 的版本

• appVersion: chart 内应用的版本，比如 redis 的版本

• kubeVersion: 兼容的 k8s 版本

• keywords: 关键词，在 helm search 中用到

• dependencies: 依赖的 chart

• mantainers: chart 的开发人员

• icon: chart 图标，会在 hub 中展示

template

template 存放 chart 中的主要内容，主要以模板的形式存在，template 中可以使用变量、控制语句、函数等，功能非常丰富。

chart hub & chart repo

• chart hub：可以理解为 chart 仓库的汇总，官方地址：https://artifacthub.io/

• chart repo：chart 仓库，存放具体的 chart

• 示例：https://charts.bitnami.com/bitnami

• 开源的仓库：harbor (https://goharbor.io/)（利用 helm OCI 的支持）

• helm 官方提供的仓库：chartmuseum - https://github.com/helm/chartmuseum

• chart repo UI：https://github.com/helm/monocular

helm CICD

可以使用 helm 来构建 CICD pipeline，下面是一个 CICD 的示例：

可以看到，整个 CICD 分为 3 个步骤，当然这只是一个例子，开发者可以根据实际的需要对这个步骤进行调整：

• stage1：开发人员编码、自测通过后，提交 feature 分支，并触发 pipeline 构建，并分别产生具有相同 tag 的 docker image 和 helm chart，并部署 helm chart。

• stage2：reviewer review 代码，测试通过后 merge 到 release 分支，修改版本号，并产生 new tag 的 docker image 和 helm chart，并部署到集群。

• stage3：测试、产品、客户，在 staging 上验证通过后，直接把 helm chart 部署到生产环境。

从 helm v2 到 v3 都有哪些变化

从下图中看到，最大的变化就是移出了 tiller，主要原因是 k8s 早已支持了 RBAC，不再需要 tiller 这么一个“多余”的组件来做权限管理了，另外的几个修改如下图所示，要了解细节，请参考官方的文档。

附录

helm 入门教程地址: https://github.com/zkf1317/cloud-native-tutorial