简介
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 也是可以的。