2. Helm 基础回顾:Chart 结构、模板引擎、Values 文件、Release 管理、Helm v3 核心特性
在深入多集群变更门禁与回滚策略之前,必须重新夯实 Helm 的核心基础。Helm 是 Kubernetes 生态中事实标准的包管理工具,它将应用定义、依赖、配置与生命周期管理封装为 Chart。本章从五个维度展开:Chart 的物理结构、模板引擎的工作机制、Values 的层次化注入、Release 的生命周期状态机,以及 Helm v3 相比 v2 的关键架构变化。
2.1 Chart 目录结构与元数据
一个标准的 Helm Chart 遵循固定的目录布局,Kubernetes 资源模板存放在 templates/ 目录下,Chart 自身的元数据由 Chart.yaml 定义。
| 文件/目录 | 作用 | 是否必须 |
|---|---|---|
Chart.yaml | Chart 名称、版本、API 版本、描述、关键字等元数据 | 是 |
values.yaml | 默认配置值,供模板引用 | 推荐 |
templates/ | Go 模板文件,渲染后生成 Kubernetes 资源清单 | 是 |
charts/ | 子 Chart 依赖(Helm v3 通过 Chart.lock 管理) | 按需 |
crds/ | 自定义资源定义(CRD),在模板渲染前安装 | 按需 |
README.md | Chart 使用说明 | 推荐 |
templates/ 目录下的文件全部经过 Go 模板引擎处理,非 .yaml 或 .tpl 后缀的文件会被忽略。Helm v3 不再需要 requirements.yaml,依赖统一在 Chart.yaml 的 dependencies 字段声明。
2.2 模板引擎与内置函数
Helm 使用 Go 标准库 text/template 作为模板引擎,并扩展了 60+ 内置函数(Sprig 库 + 自定义函数)。模板通过 {{ }} 双花括号语法访问 Values、内置对象和管道函数。
# 典型的 Deployment 模板片段 (templates/deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-{{ .Chart.Name }}
labels:
app.kubernetes.io/name: {{ .Chart.Name }}
app.kubernetes.io/instance: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicaCount | default 1 }}
template:
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default "latest" }}"
ports:
- containerPort: {{ .Values.service.port }}
模板中可访问的 内置对象 包括:
.Values— 用户传入的配置值(合并默认值后).Release— Release 元数据(Name、Namespace、Revision、Service、IsUpgrade、IsInstall).Chart— Chart.yaml 中的字段(Name、Version、AppVersion、Annotations).Files— 访问 Chart 内非模板文件(如配置文件、证书).Capabilities— 目标集群的 Kubernetes 版本与 API 版本信息
required 函数强制校验必填 Values,避免空值导致资源创建失败。例如:{{ required "image.repository is required" .Values.image.repository }}
2.3 Values 文件层次与优先级
Helm 支持多级 Values 注入,优先级从低到高依次为:Chart 内建 values.yaml → 父 Chart 的 values → -f 指定的外部文件(可多个)→ --set 命令行参数。合并策略是深度合并(deep merge),而非简单覆盖。
# 默认 values.yaml
replicaCount: 2
image:
repository: nginx
tag: "1.25"
service:
type: ClusterIP
port: 80
# 生产环境覆盖文件 values-prod.yaml
replicaCount: 5
image:
tag: "1.25-alpine" # 只覆盖 tag,repository 保留默认值
2.4 Release 管理与版本状态机
Release 是 Chart 的一次部署实例。Helm v3 将 Release 信息存储在集群内的 Secret 中(命名空间隔离),每个 Release 包含多个 Revision(版本)。
| 命令 | 作用 | Revision 变化 |
|---|---|---|
helm install | 首次部署,创建 Release 并生成 Revision 1 | +1 |
helm upgrade | 升级到新版本,生成下一个 Revision | +1 |
helm rollback | 回滚到指定 Revision | +1(新 Revision 指向旧版本) |
helm uninstall | 删除 Release,可指定 --keep-history 保留 Revision 记录 | 标记删除 |
Revision 状态流转:pending-install → deployed / failed → superseded(被新版本替代)→ pending-rollback → deployed。
helm rollback RELEASE REVISION 本质是创建一个新的 Revision,其模板与目标 Revision 相同。这意味着回滚操作本身是可审计、可回退的,不会丢失历史。
2.5 Helm v3 核心特性与架构变化
Helm v3 移除了 Tiller(服务端组件),改为纯客户端架构,安全性、RBAC 集成和命名空间隔离得到根本性改善。
Helm v3 的其他关键特性:
- OCI 注册表支持:Chart 可以打包为 OCI 镜像,存储在 Harbor、ECR 等容器镜像仓库中,不再依赖 Chart Museum。
- Library Chart:一种特殊 Chart 类型,只提供模板辅助函数(
_helpers.tpl),不生成任何资源,适合多 Chart 共享逻辑。 - JSON Schema 校验:在
values.schema.json中定义 Values 的约束条件,helm install/upgrade时自动校验。 - Post-Render 钩子:允许在模板渲染后、提交到 Kubernetes 之前,通过外部工具(如 Kustomize)对清单进行二次处理。
helm 2to3 插件自动转换 Release 存储(ConfigMap → Secret)并清理 Tiller。迁移后务必验证所有 helm list 输出正确。