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.yamlChart 名称、版本、API 版本、描述、关键字等元数据是
values.yaml默认配置值,供模板引用推荐
templates/Go 模板文件,渲染后生成 Kubernetes 资源清单是
charts/子 Chart 依赖(Helm v3 通过 Chart.lock 管理)按需
crds/自定义资源定义(CRD),在模板渲染前安装按需
README.mdChart 使用说明推荐
关键点: 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 保留默认值
注意: 列表(数组)类型的 Values 在合并时是整体替换,而非按索引合并。如果需要在不同环境追加列表项,建议使用 YAML 锚点或通过模板逻辑拼接。

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 v2 vs v3 架构对比 Helm v2(Tiller 架构) Helm Client (CLI) Tiller (服务端) Kubernetes API ConfigMap (Release) Tiller 拥有集群级权限 Release 存储在 ConfigMap 跨命名空间管理风险 RBAC 难以细粒度控制 Helm v3(无 Tiller) Helm Client (CLI) Kubernetes API Secret (Release) 客户端直接调用 Kubernetes API Release 存储在 Secret(加密) 使用当前 kubeconfig 的 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 v2 迁移到 v3 时,使用 helm 2to3 插件自动转换 Release 存储(ConfigMap → Secret)并清理 Tiller。迁移后务必验证所有 helm list 输出正确。

2.6 本章小结