Helm 包管理入门

如果说 Kustomize 是”给 YAML 打补丁”，那 Helm 就是”给应用打包”。它像 yum、apt 之于操作系统一样，把一整套 Kubernetes 资源打包成一个 Chart，让你一条命令就能装好一个复杂应用。

54-1 三个核心概念

初次接触 Helm，先记住这三个词：

• Chart（图表）：一个应用的可安装包，里面是模板化的 Kubernetes 清单，相当于 rpm 或 deb 文件。
• Repository（仓库）：存放和分发 Chart 的地方，类似软件源。
• Release（发布）：Chart 被安装到集群后的一个实例。同一个 Chart 可以装出多个 Release。

在 Helm 3 里，客户端 helm 直接和 Kubernetes API 通信，不再需要服务端组件。这比早期的 Helm 2（带 Tiller）简洁、也安全得多。本教程只讲 Helm 3 的主流用法。

54-2 一个 Chart 里有什么

用命令创建一个骨架：

helm create example-chart

典型结构如下：

example-chart
├── Chart.yaml        # 元数据：名称、版本、描述
├── values.yaml       # 默认参数，用户可覆盖
├── charts/           # 依赖的其他 Chart
└── templates/        # 真正的 Kubernetes 清单模板
    ├── deployment.yaml
    ├── service.yaml
    ├── _helpers.tpl  # 公共模板函数
    └── tests/        # 安装后的连通性测试

templates/ 里的文件是 Go 模板。模板里用 {{ .Values.xxx }} 引用参数，把”部署什么”和”参数怎么填”彻底分开。这样多套环境、多个实例可以复用同一份 Chart。

values.yaml 是最主要的配置文件。比如里面定义了镜像名、副本数、Service 类型。安装时你既可以用 -f 指定自己的 values 文件，也能用 --set 临时改单个值。

54-3 发布与查看

装之前先验证 Chart 写得对不对：

helm lint example-chart
helm install --dry-run --debug helm-nginx example-chart

正式发布：

helm install helm-nginx example-chart

看看装了什么：

helm ls
helm status helm-nginx --show-resources

查看渲染后的真实配置，这条命令排错时特别有用：

helm get values helm-nginx

54-4 升级与回滚

改了 values.yaml 或 Chart 内容后，用 upgrade 更新：

helm upgrade helm-nginx example-chart -f values.yaml --set service.type=NodePort

每次升级，REVISION 号都会加一。想反悔？回滚到任意历史版本：

helm history helm-nginx
helm rollback helm-nginx 1

彻底删除发布，新版本用 uninstall 直接移除所有相关资源：

helm uninstall helm-nginx

54-5 模板里的参数从哪来

模板里常见的变量来源有三类：

• .Values 开头：定义在 values.yaml 或 --set 传的值。
• .Chart 开头：来自 Chart.yaml 的元数据。
• .Release 开头：安装时由 Helm 决定的，比如发布名称、命名空间。

一个简化版的 Deployment 模板长这样：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "example-chart.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

_ 开头的 _helpers.tpl 用来放公共函数，避免模板臃肿。模板引擎还支持 if、range 等控制结构，比如用 if .Values.ingress.enabled 来决定是否渲染 Ingress。

54-6 钩子与调试

Helm 的钩子（hook）能在安装前、安装后、删除前等时机执行特定操作，比如安装前先建 Secret、升级前做检查。钩子通过注解声明：

annotations:
  "helm.sh/hook": pre-install,post-upgrade
  "helm.sh/hook-weight": "-5"

想确认模板渲染结果，除了 --dry-run，还可以直接看展开后的样子：

helm template helm-nginx example-chart

54-7 仓库与打包

官方和社区有大量现成 Chart，比如 Bitnami、Elastic 的仓库。添加并搜索：

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx

自己写的 Chart 也能打包分享：

helm package example-chart

54-8 什么时候用 Helm

Helm 适合”把一个复杂应用整体交付”。数据库、监控系统、中间件这类由多个资源组成、需要统一版本管理的场景，用 Helm 最省心。

不过 Helm 的模板有一定学习曲线。如果你的需求只是多环境微调几处配置，第 53 章的 Kustomize 可能更轻。两者可以组合：用 Helm 装应用，用 Kustomize 管环境差异，也是常见做法。

一句话：Helm 把”部署一个应用”变成”安装一个包”，这正是它流行的原因。