简介
Helm 就是k8s 的包管理器 。常见的包管理器有：yum,apt,pip…
包管理器基础功能有：
- 安装
- 依赖安装
- 升级
- 回滚
- 卸载
- 源管理
- 搜索
- …
基本概念
Helm: Kubernetes的包管理工具，命令行同名
Tiller: Helmv2 的服务端，用于接收并处理 Helm 发送的请求，默认以 Deployment 形式部署在 k8s 集群中
Chart: Helm 包管理的基础单元，等同于 RPM
Repoistory: Helm的软件源仓库，是一个 Web 服务器，路径下除了响应的软件 Chart 包之外，维护了一个 index.yaml 用于索引
Release: Helm 安装在 Kubernetes 集群中的 Chart 实例
现状
helm 截至06月20日最新稳定版本为 v2.14.1。
在05月16日发布了 v3.0 alpha 版本，根据相关文档描述，v2 无法平滑升级到 v3 版本。
注：存在部分小版本无法平滑升级情况。
helm v3 版本改进：
- 在 v2 版本设计中，需要单独创建属于 Tiller 的 ServiceAccount，授权 clusteradmin 权限，以为着只要你有 helm 权限，那么你有操作 k8s全集群所有权限。在 v3 版本中删除 Tiller，直接与 k8s api 进行通信，权限管理更清晰
- helm 提供 libary
- 模板引擎切换为 Lua
- 目前通过 Hook 方式创建的资源，helm 后续不会管理，在 v3 会增加管理 Hook 资源功能
- 目前所有配置保存在 cm 中，后续考虑保存到 secret
- v2 需要单独维护仓库，v3 中可以将 Chart 推送到 Docker 镜像仓库中，提供 helm push/login 功能
- …
Helm2 基本使用
安装
在 Helm Github Release 下载最新版本二进制文件，并在本地解压。
在 k8s master 节点，执行 helm init --server-account tiller 将 Tiller 部署在 k8s 集群中，指定 Service Account 为 Tiller。
在 k8s 1.6 版本之后，需要创建对应的 ServiceAccount 资源给 Tiller ，便于 Tiller 后续创建资源，参考官方文档：
rbac-config.yaml1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18apiVersion: v1
kind: ServiceAccount
metadata:
name: tiller
namespace: kube-system
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: tiller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
1 | $ kubectl create -f rbac-config.yaml |
通过 helm version 验证是否部署成功，成功会显示 client 和 server 对应版本。
1 | [root@node1 helm]# helm version |
基本使用
Chart构建
本地创建一个测试软件包：
1 | [root@node1 helm]# helm create yiran-test |
有了基础示例，我们可以先通过 dry-run 方式跑一下：
1 | [root@node1 yiran-test]# helm install --dry-run --debug ./ |
安装
可以看到生成的 YAML 文件就是拿 values.yaml 值渲染模板生成的，那么我们来安装一下：
1 | [root@node1 yiran-test]# helm install ./ |
注意，此时我们已经创建好了对应的资源，可以通过 kubectl 来查看状态。
升级
我们来修改一下 yiran-test/Chart.yaml ，调整下版本，进行升级：
1 | [root@node1 yiran-test]# cat Chart.yaml |
回滚
通过上述步骤，我们已经把我们的应用 yiran-test 从 0.1.0 版本升级到了 0.2.0 版本，那么我们现在来尝试下回滚。
helm 回滚操作需要指定 Release 名称和目标版本：
1 | [root@node1 yiran-test]# helm list |
嗯，可以看到，我们指定了回滚的目标 REVISION，回滚成功了，yiran-test 回到了 0.1.0 版本，但是，最恶心的来了，Release 的当前版本变成了 3 ，而不是设想中的 1 。
卸载
如果我们想要从 k8s 上卸载对应的软件，也就是我们的 yiran-test ，我们可以直接执行 delete 命令，会直接把相关资源全部删除掉。
1 | [root@node1 ~]# helm list |
软件源管理
上面我们所有的操作都是针对本地包（路径），那么我们怎么才能通过网络下载别人已经构建好的软件包呢？
helm 使用 repo 命令来管理软件源，使用上也很简单，简单列举下相应命令实用说明：
1 | [root@node1 ~]# helm repo list |
软件搜索
1 | [root@node1 ~]# helm search mongo |
打包与本地软件源构建
Helm v2 命令支持本地创建软件源，命令关键字是 helm serve ，下面来演示下相关操作：
启动本地源，并指定 IP 地址和 repo 路径：1
2
3
4
5
6
7[root@node1 helm]# pwd
/root/helm
[root@node1 helm]# ls
rbac-config.yaml yiran-test
[root@node1 helm]# helm serve --address 192.168.27.231:8879 --repo-path /root/helm/
Regenerating index. This may take a moment.
Now serving you on 192.168.27.231:8879
新开终端，通过修改 yiran-test 的 Chart.yaml 文件打包两个版本的 Chart：
1 | [root@node1 helm]# cat yiran-test/Chart.yaml |
此时访问浏览器，应该只能看到空的列表，我们更新一下软件源索引：
1 | [root@node1 helm]# helm repo index --url=http://192.168.27.231:8879 . |
可以看到在 repo 路径下生成了一个 index.yaml 文件，这个文件就是 repo 的索引文件，我们可以直接通过浏览器访问 http://192.168.27.231:8879 来浏览或下载所需软件包。
也可以将本地 repo 添加到 helm 中，使用 helm 命令将软件包部署到 k8s 中：
1 | [root@node1 helm]# helm repo list |
尝试从本地源安装应用：
1 | [root@node1 helm]# helm list |
Chart 依赖管理
包管理器一个比较钟要的功能就是依赖管理，当我安装 A，A 依赖于 B，那么 B 应该会自动安装完成。
我们在 yiran-test 中添加两个依赖，并构建：
1 | [root@node1 helm]# cat yiran-test/requirements.yaml # 添加 apache 和 mysql 依赖 |
可以看到 helm 对依赖的管理方式是将自己所依赖的所有 Chart，均下载到 yiran-test/charts/ 路径下，我们打包的时候其实已经包含了所有依赖了。
再创建一个 Chart，依赖于 yiran-test ：
1 | [root@node1 helm]# tree nested/ |
实际安装 nested ，来看下安装结果：
1 | [root@node1 helm]# helm install nested/ |
我们可以看到 nested 已经安装完成了，同时 nested 依赖得 yiran-test 及 yiran-test 依赖得 mysql & apache 也已经安装了。
具体得依赖关系直接引用官方文档示例：
假设名为 “A” 的 chart 创建以下 Kubernetes 对象
namespace “A-Namespace”
statefulset “A-StatefulSet”
service “A-Service”
此外，A 依赖于创建对象的 chart B.
namespace “B-Namespace”
replicaset “B-ReplicaSet”
service “B-Service”
安装/升级 chart A 后，会创建/修改单个 Helm 版本。该版本将按以下顺序创建/更新所有上述 Kubernetes 对象：
A-Namespace
B-Namespace
A-StatefulSet
B-ReplicaSet
A-Service
B-Service
这是因为当 Helm 安装 / 升级 charts 时，charts 中的 Kubernetes 对象及其所有依赖项都是如下
- 聚合成一个单一的集合;
- 按类型排序，然后按名称排序;
- 按该顺序创建/更新。
因此，单个 release 是使用 charts 及其依赖关系创建的所有对象，这意味着 Helm 不管理依赖服务的相关启动顺序，要由上层应用自己控制（比如创建响应探针）。
具体的资源创建顺序可以看 Tiller 相关代码。
总结
总体来说 Helm 基础功能使用还是很方便的，关键在于我们如何划分我们应用的粒度，比如 openstack 是以组件为粒度划分的：nova Chart 包含 api、scheduler、conductor 等服务；比如 TiDB Operator 项目是以具体功能来划分的：tidb-backup、tidb-cluster、tidb-operator 。我们应该根据自己的业务需求，合理划分。
还有一点需要注意的是，Helm 项目还处于快速发展阶段（貌似涉及 k8s 的都变化太快），尤其是最近发布了 Helm3 alpha，如果是生产系统，需要考虑后续是否能够平滑升级的影响。
如果实在不喜欢 Helm Tiller 方式，单纯使用 Helm template 也是可以的。