3. Helm 升级流程回顾：工作原理、Revision 管理、Rollback 机制与升级钩子

在生产环境中执行 helm upgrade 是变更交付的核心操作。理解其底层工作原理、Revision 版本管理、回滚机制以及升级钩子，是进行故障域隔离与节点排空参数调优的前提。本节将系统梳理 Helm 升级的完整生命周期。

3.1 helm upgrade 工作原理

helm upgrade 并非简单的“替换”，而是一个三阶段原子操作：

1. 计算 Diff（差异计算）：Helm 将新 Chart 模板与当前 Release 的 Manifest 进行对比，生成补丁集。
2. 构建新 Release：基于新 Chart 和用户提供的 Values，渲染出完整的 Kubernetes 资源清单。
3. 执行 Apply（应用）：通过 Kubernetes API Server 对资源进行创建、更新或删除操作。

3.2 Revision 管理机制

Helm 使用 Revision（修订版本） 来追踪 Release 的每一次变更。每次 helm upgrade 或 helm install 都会生成一个新的 Revision 编号，从 1 开始递增。

3.3 Rollback 回滚机制

helm rollback 允许将 Release 恢复到之前的任意 Revision。其工作原理如下：

• 读取历史 Manifest：从目标 Revision 的 Secret 中提取完整的资源清单。
• 计算差异：对比当前 DEPLOYED 版本与目标版本的差异。
• 执行回滚 Apply：将资源状态恢复到目标 Revision 的期望状态。
• 生成新 Revision：回滚操作本身会创建一个新的 Revision（编号递增），而不是覆盖历史。

3.4 升级钩子（Hooks）

Helm 钩子允许在 Release 生命周期的特定节点执行自定义操作。升级相关的钩子按执行顺序如下：

3.5 升级流程完整时序

以下是一个完整的 helm upgrade --atomic 时序流程：

1. 用户执行 helm upgrade my-release ./chart --atomic
2. Helm 读取当前 Release 的 DEPLOYED Revision（如 v2）
3. 渲染新 Chart 模板，生成新 Manifest
4. 执行 pre-upgrade 钩子（如果有）
   ├── 成功 → 继续
   └── 失败 → 终止升级，不创建新 Revision
5. 通过 K8s API 逐个 Apply 资源（创建/更新/删除）
   ├── 全部成功 → 创建新 Revision（v3），状态 DEPLOYED
   └── 任何失败 → 触发自动回滚
       ├── 读取 v2 Manifest
       ├── 执行 pre-rollback 钩子
       ├── 恢复资源到 v2 状态
       ├── 执行 post-rollback 钩子
       └── 创建新 Revision（v3），状态 FAILED
6. 执行 post-upgrade 钩子（即使回滚也会执行）
7. 输出升级结果