2. Helm 基础回顾：Chart 结构、模板引擎、Values 文件、Release 生命周期

在深入 GitOps 与变更门禁之前，必须重新夯实 Helm 的核心概念。Helm 是 Kubernetes 的包管理工具，它将应用的定义、配置、依赖打包为一个标准化的 Chart。本节将拆解 Chart 的物理结构、模板渲染机制、Values 注入方式以及 Release 的完整生命周期，为后续的配额变更与回滚判断建立共同语言。

2.1 Chart 目录结构

一个标准的 Helm Chart 遵循固定的目录布局。以下是一个典型 Chart 的骨架：

my-app/
├── Chart.yaml          # 元数据：名称、版本、API 版本、依赖
├── values.yaml         # 默认配置值（用户可覆盖）
├── values.schema.json  # （可选）Values 的 JSON Schema 校验
├── charts/             # （可选）子 Chart 或依赖包
├── templates/          # 模板文件目录（核心）
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # 命名模板（函数）
│   └── NOTES.txt       # 安装后的提示信息
└── crds/               # （可选）CRD 定义，仅安装一次
文件/目录 作用 变更频率
Chart.yaml 定义 Chart 名称、版本、appVersion、依赖声明 低（版本升级时修改）
values.yaml 提供默认配置，用户通过 --set 或自定义 values 文件覆盖 中（随环境参数调整）
templates/ Go 模板 + YAML 清单，最终渲染为 Kubernetes 资源 高（业务逻辑变更）
charts/ 存放子 Chart 或通过 helm dependency 下载的 tgz 低（依赖更新时）
crds/ 自定义资源定义，helm install 时优先安装 极低（仅首次或升级 CRD 版本）
实践要点： 在 GitOps 场景中，values.yaml 通常作为“基线”，环境差异通过 values-production.yaml 或 values-staging.yaml 在 Git 仓库中管理，避免直接修改 Chart 内的默认值。

2.2 模板引擎与渲染流程

Helm 使用 Go 的 text/template 引擎，并扩展了 sprig 函数库。模板引擎的核心工作是将 模板文件 + Values 渲染为纯 YAML。渲染流程如下：

  1. 加载 Chart：读取 Chart.yaml 和 values.yaml。
  2. 合并 Values：用户提供的 --values / --set 覆盖默认值，形成最终 Values 对象。
  3. 解析依赖：如果存在子 Chart，递归加载并合并其 Values（全局值传递）。
  4. 执行模板：遍历 templates/ 目录，对每个 .yaml / .tpl 文件执行 Go 模板渲染。
  5. 校验输出：对渲染后的 YAML 进行基本结构校验（非 Schema 校验）。
  6. 生成 Release 对象：将渲染后的资源清单打包为 Release 记录，存储于集群 Secret 中。
关键命令：
helm template my-release ./my-chart — 仅渲染模板到终端，不安装，用于调试。
helm install my-release ./my-chart --dry-run --debug — 模拟安装并输出渲染结果与 Values 合并过程。
Helm 模板渲染流程 Chart.yaml values.yaml Values 合并 模板引擎 YAML 输出 templates/*.yaml Release Secret 说明：用户通过 --set 或 --values 提供的值在“Values 合并”阶段覆盖默认值。 模板引擎使用 Go 模板语法 + sprig 函数，最终输出纯 YAML 并存储为 Release 记录。

2.3 Values 文件与作用域

Values 是 Helm 模板的数据源。理解其作用域规则对 GitOps 中的多环境配置至关重要。

来源 优先级（高→低） 示例
--set / --set-string 1（最高） --set image.tag=v2.0
--values 指定文件 2 --values prod-values.yaml
父 Chart 的 values.yaml 3 子 Chart 继承父 Chart 的全局值
子 Chart 自身的 values.yaml 4（最低） 子 Chart 默认值
常见陷阱： 在 GitOps 工具（如 ArgoCD/Flux）中，--set 参数通常被映射为 Helm 参数或 Kustomize 补丁。如果直接在 Git 仓库中硬编码 --set，会导致声明式配置与运行时状态不一致。推荐将所有环境差异写入独立的 values 文件并纳入版本控制。

2.4 Release 生命周期

一个 Release 是 Chart 的一次部署实例。Helm 管理 Release 的完整状态变迁，这是实现回滚判断的基础。

  • Pending-install：Helm 正在执行安装操作，资源尚未完全创建。
  • Deployed：安装成功，所有资源正常运行。
  • Failed：安装或升级过程中发生错误，部分资源可能已创建。
  • Pending-upgrade：正在执行升级操作。
  • Pending-rollback：正在执行回滚操作。
  • Superseded：被新版本替代的历史 Release 版本。
  • Uninstalled：已卸载，但 Release 记录保留（默认保留历史）。
Helm Release 状态机 Pending-install Deployed Failed Pending-upgrade Pending-rollback Superseded Uninstalled 说明：回滚操作会创建一个新的 Release 版本（版本号递增），并将状态设置为 Deployed 或 Failed。

2.5 关键命令速查

操作 命令 说明
安装 helm install [name] [chart] 创建 Release，版本号 = 1
升级 helm upgrade [name] [chart] 创建新版本，版本号递增
回滚 helm rollback [name] [revision] 回退到指定版本，版本号继续递增
查看历史 helm history [name] 列出所有版本及其状态
卸载 helm uninstall [name] 删除资源，保留 Release 记录
GitOps 关联： 在 GitOps 工作流中，helm upgrade --install 是标准操作。ArgoCD 和 Flux 均使用此模式实现“期望状态”与“实际状态”的同步。回滚操作在 GitOps 中通常通过 Git revert 触发，而非直接执行 helm rollback，以保持 Git 作为单一事实来源。
← 上一章 📖 返回目录 下一章 →