2. Helm 基础回顾：架构、Chart 结构、Release 管理与核心命令
在深入多集群回滚策略之前，必须重新夯实 Helm 的核心概念。Helm 是 Kubernetes 的包管理工具，它将应用及其依赖打包为 Chart，通过 Release 机制管理每次部署的生命周期。本节将系统梳理 Helm v3 的架构、Chart 目录规范、Release 状态机以及 install、upgrade、rollback 三个核心命令的执行细节。
2.1 Helm v3 架构：无 Tiller 的客户端直连模式
Helm v3 移除了服务端组件 Tiller，采用纯客户端架构。CLI 直接通过 kubeconfig 与 Kubernetes API Server 通信，显著提升了安全性和部署效率。
架构要点： Helm v3 的客户端直连模式消除了服务端组件，使得多集群部署时只需切换 kubeconfig 即可操作不同集群，无需在每个集群中部署 Tiller。Release 记录以 Secret 形式存储，天然支持加密和 RBAC 控制。
2.2 Chart 目录结构：标准规范与关键文件
一个标准的 Helm Chart 遵循固定目录布局。理解每个文件的作用是编写可回滚 Chart 的前提。
| 文件/目录 | 是否必需 | 作用说明 |
|---|---|---|
Chart.yaml |
是 | Chart 元数据：名称、版本、apiVersion、appVersion、描述、依赖列表 |
values.yaml |
是 | 默认配置值，供模板引用；回滚时需保留历史 values 快照 |
templates/ |
是 | Go 模板文件目录，渲染后生成 Kubernetes 资源清单 |
charts/ |
否 | 子 Chart 依赖目录（手动或通过 helm dependency 管理） |
crds/ |
否 | 自定义资源定义（CRD），在 install 时优先安装 |
templates/NOTES.txt |
否 | 安装成功后输出的使用说明文本 |
templates/tests/ |
否 | 测试 Pod 模板，用于 helm test 验证部署 |
回滚视角：
values.yaml 和 templates/ 是回滚的核心。Helm 在每次 upgrade 时会保存一份完整的 values 快照和渲染后的 manifest，rollback 时直接复用这些历史数据，而非重新读取当前 Chart 目录。
2.3 Release 管理：状态机与版本历史
Release 是 Chart 的一次部署实例。Helm v3 使用 3 层状态机 管理 Release 生命周期：pending → deployed / failed → superseded / uninstalled。
回滚关键约束： 只能回滚到 deployed 或 superseded 状态的版本。如果某个版本已被
helm delete 标记为 uninstalled，则无法直接回滚，必须重新 install。
2.4 核心命令详解：install / upgrade / rollback
2.4.1 helm install：首次部署
将 Chart 部署到目标集群，生成 Release 版本 1。
# 基本语法
helm install [RELEASE_NAME] [CHART] [flags]
# 示例：部署 my-app，指定 values 文件
helm install my-release ./my-chart \
--values prod-values.yaml \
--namespace production \
--create-namespace \
--atomic \
--timeout 5m| 参数 | 说明 | 回滚相关性 |
|---|---|---|
--atomic |
安装失败时自动回滚到未安装状态 | 高：确保首次部署失败不留残留 |
--wait |
等待所有 Pod 进入 Ready 状态 | 高：避免回滚时依赖未就绪资源 |
--timeout |
等待超时时间（默认 5m） | 中：超时导致 failed 状态，影响后续回滚 |
--values |
指定自定义 values 文件 | 高：values 快照是回滚恢复的依据 |
2.4.2 helm upgrade：更新与回滚的触发点
升级 Release 到新版本。每次 upgrade 都会生成一个新的 Revision，并将旧 Revision 标记为 superseded。
# 基本语法
helm upgrade [RELEASE_NAME] [CHART] [flags]
# 示例：升级 my-release，使用新 values
helm upgrade my-release ./my-chart \
--values prod-values-v2.yaml \
--namespace production \
--atomic \
--cleanup-on-fail \
--history-max 10| 参数 | 说明 | 回滚相关性 |
|---|---|---|
--cleanup-on-fail |
升级失败时自动清理新创建的资源 | 高：减少回滚前的脏数据 |
--history-max |
保留的历史版本数（默认 10） | 高：限制回滚可选范围，防止存储膨胀 |
--reuse-values |
复用上一次的 values（不推荐用于生产） | 中：可能导致 values 不一致，回滚后行为异常 |
--reset-values |
重置 values 为 Chart 默认值 | 中：与 --reuse-values 互斥，需谨慎使用 |
升级与回滚的关联：
helm upgrade 是回滚的“前置动作”。只有执行过 upgrade 产生多个 Revision，才能执行 rollback。在多集群门禁场景中，每次 upgrade 都应触发变更门禁检查，通过后才允许写入集群。
2.4.3 helm rollback：核心回滚命令
将 Release 恢复到指定历史版本。Helm 会重新应用该版本对应的 manifest 和 values。
# 基本语法
helm rollback [RELEASE_NAME] [REVISION] [flags]
# 示例：回滚到版本 3
helm rollback my-release 3 \
--namespace production \
--atomic \
--wait \
--timeout 5m \
--force
# 查看历史版本列表
helm history my-release --namespace production| 参数 | 说明 | 使用场景 |
|---|---|---|
--force |
强制替换资源（删除后重建） | 当资源无法原地更新时使用（如变更了 immutable 字段） |
--recreate-pods |
重建所有 Pod（已弃用，推荐 --force） |
兼容旧版本，新项目使用 --force |
--cleanup-on-fail |
回滚失败时清理本次回滚创建的资源 | 防止回滚失败导致集群状态混乱 |
--no-hooks |
跳过 pre/post 钩子 | 紧急回滚时避免钩子执行失败阻塞 |
回滚的副作用： 回滚本身会生成一个新的 Revision（版本号递增）。例如从 Revision 5 回滚到 Revision 3，会生成 Revision 6，其内容与 Revision 3 相同。这意味着回滚不是“撤销”，而是“创建历史状态的副本”。
2.5 核心概念对比：install vs upgrade vs rollback
| 维度 | helm install | helm upgrade | helm rollback |
|---|---|---|---|
| 初始版本 | 生成 Revision 1 | 生成 Revision N+1 | 生成 Revision N+1（内容等于历史版本） |
| Chart 来源 | 本地目录或仓库 | 本地目录或仓库 | 复用历史 Release 的 manifest |
| Values 来源 | 用户指定 + 默认值 | 用户指定 + 默认值 | 复用历史 Release 的 values 快照 |
| 资源变更 | 创建全部资源 | 增量更新（diff 后 patch） | 增量更新（diff 后 patch） |
| 失败处理 | --atomic 自动清理 |
--atomic 自动回滚到上一版本 |
--atomic 自动回滚到回滚前的版本 |
| 多集群适用性 | 需逐集群执行 | 需逐集群执行，可配合门禁 | 需逐集群执行，可配合门禁 |
多集群门禁中的命令选择： 在变更门禁流程中，
helm upgrade 是“变更提交”的入口，helm rollback 是“变更回退”的出口。建议在 CI/CD 流水线中为每个集群独立执行 upgrade，并记录每个集群的 Revision 号，以便在门禁检测到异常时精准回滚指定集群。
2.6 本章小结
- 架构：Helm v3 无 Tiller，客户端直连 API Server，Release 存储在 Secret 中。
- Chart 结构：
Chart.yaml+values.yaml+templates/是核心三要素，回滚依赖历史 values 快照。 - Release 状态机：
pending→deployed/failed→superseded/uninstalled，只能回滚到deployed或superseded版本。 - 命令关系：install 创建基线，upgrade 产生新版本，rollback 创建历史副本。三个命令均支持
--atomic和--wait保证操作完整性。 - 多集群视角：每个集群的 Release 版本独立演进，门禁系统需要维护集群-Release-Revision 的映射关系。