4. Helm 发布管理：生命周期与回滚策略

Helm 的发布管理是 Kubernetes 应用交付的核心控制面。每一次 helm install、helm upgrade、helm rollback 或 helm delete 操作，都会在目标集群中创建一个 Release 记录，并生成一个递增的 Revision 版本号。理解这个生命周期模型，是诊断 DNS 延迟、SLO 违约后快速回滚的基础。

4.1 Release 生命周期模型

一个 Helm Release 从创建到删除，经历以下四个核心阶段：

阶段 命令 核心行为 Revision 变化
安装 helm install 将 Chart 模板渲染为 Kubernetes 清单并 apply 到集群，创建 Release 记录 Revision 1
升级 helm upgrade 基于新 values 或新 Chart 重新渲染，执行 patch/update 操作 Revision N+1
回滚 helm rollback 将集群状态恢复到指定 Revision 的渲染结果 Revision N+1（新版本）
删除 helm delete 删除 Release 记录及关联的 Kubernetes 资源（默认保留历史） 标记为 DELETED
关键认知： Helm 的 rollback 本质上是一次特殊的 upgrade。它会基于目标 Revision 的渲染结果生成一个新的 Revision，而不是直接“跳回”旧版本。这意味着回滚后集群状态与旧版本一致，但 Revision 号是递增的。

4.2 Revision 版本号与存储机制

每个 Release 的 Revision 历史默认存储在 Kubernetes 的 Secret 资源中（命名空间：kube-system 或 Release 所在命名空间）。Revision 号从 1 开始单调递增，永不重复。

# 查看指定 Release 的所有 Revision
helm history my-release -n production

# 输出示例
REVISION	UPDATED                 	STATUS    	CHART            	APP VERSION	DESCRIPTION
1       	Mon Jan 15 10:00:00 2024	DEPLOYED  	web-app-2.1.0    	2.0.0     	Install complete
2       	Mon Jan 15 11:30:00 2024	DEPLOYED  	web-app-2.2.0    	2.1.0     	Upgrade complete
3       	Mon Jan 15 12:15:00 2024	SUPERSEDED	web-app-2.2.0    	2.1.0     	Rollback to 1
4       	Mon Jan 15 12:45:00 2024	DEPLOYED  	web-app-2.3.0    	2.2.0     	Upgrade complete
Revision 状态说明：
  • DEPLOYED：当前生效的 Revision。
  • SUPERSEDED：已被后续升级或回滚覆盖的历史版本。
  • FAILED：安装或升级过程中发生错误。
  • DELETED：Release 已被删除，但历史记录保留（可通过 --keep-history 控制）。

4.3 回滚策略与 DNS 延迟场景

当 SLO 违约由 DNS 延迟引发时（例如 CoreDNS 配置错误、Service 端点更新滞后），快速回滚到上一个稳定 Revision 是最直接的止损手段。Helm 提供两种回滚策略：

策略 命令 适用场景 风险
直接回滚 helm rollback RELEASE REVISION 已知上一个 Revision 是稳定的，需要立即恢复 如果回滚目标本身有 DNS 问题，会二次故障
带 dry-run 回滚 helm rollback RELEASE REVISION --dry-run 需要先验证回滚后的资源清单，避免意外变更 耗时较长，不适合紧急止损 
# 紧急回滚到 Revision 2（假设该版本 DNS 正常）
helm rollback my-release 2 -n production

# 回滚前先 dry-run 验证
helm rollback my-release 2 -n production --dry-run
DNS 延迟场景下的回滚注意事项：
  • 回滚操作本身会触发 Service/Endpoint 更新，可能再次引发 DNS 缓存抖动。
  • 建议在回滚前先通过 kubectl get endpoints 确认当前端点状态。
  • 如果回滚目标 Revision 的 Service 名称或端口发生变化，DNS 解析可能仍然失败。

4.4 Helm 发布管理流程（SVG）

下图展示了 Helm Release 从安装到删除的完整生命周期，以及 Revision 的演进路径：

Helm Release 生命周期与 Revision 演进 Helm Release 生命周期与 Revision 演进 helm install Revision 1 helm upgrade Revision N+1 helm rollback Revision N+1 helm delete DELETED Secret 存储：Revision 历史记录 Rev 1 (DEPLOYED) → Rev 2 (SUPERSEDED) → Rev 3 (DEPLOYED) → Rev 4 (SUPERSEDED) 说明： • rollback 会创建新 Revision，不会覆盖旧版本。 • 默认保留 10 个历史 Revision，可通过 --history-max 调整。

4.5 回滚策略配置与最佳实践

在 values.yaml 或命令行中，可以控制 Helm 的回滚行为：

# 在 upgrade 时设置最大历史保留数
helm upgrade my-release ./chart --history-max 5 -n production

# 回滚时跳过资源验证（加速回滚）
helm rollback my-release 2 --no-hooks -n production

# 回滚并等待所有 Pod 就绪
helm rollback my-release 2 --wait --timeout 5m -n production
DNS 延迟场景下的回滚最佳实践：
  1. 保留足够历史：至少保留 5-10 个 Revision，确保有多个稳定版本可供选择。
  2. 回滚前验证：使用 --dry-run 确认回滚后的 Service/Endpoint 配置。
  3. 监控回滚过程：结合 --wait 确保所有 Pod 进入 Ready 状态后再恢复流量。
  4. 避免级联回滚：如果连续两次升级都导致 DNS 问题，直接回滚到更早的 Revision，而不是逐级回退。

4.6 删除与清理策略

helm delete 默认会删除 Release 记录和关联的 Kubernetes 资源，但保留 Secret 历史。如果需要彻底清理：

# 删除 Release 并保留历史（默认）
helm delete my-release -n production

# 删除 Release 并清除所有历史
helm delete my-release --purge -n production

# 查看已删除的 Release（如果未 purge）
helm list --deleted -n production
生产环境建议： 除非磁盘空间紧张，否则不要使用 --purge。保留已删除 Release 的历史记录，可以在误删除后通过 helm rollback 恢复（需先 helm install --replace 重建 Release 记录）。

4.7 发布管理命令速查表

操作 命令 常用参数
安装 helm install RELEASE CHART --values, --set, --namespace, --create-namespace
升级 helm upgrade RELEASE CHART --install, --reset-values, --reuse-values, --history-max
回滚 helm rollback RELEASE REVISION --dry-run, --wait, --timeout, --no-hooks
删除 helm delete RELEASE --purge, --keep-history
查看历史 helm history RELEASE --max, --output
← 上一章 📖 返回目录 下一章 →