📚 课程目录第2章 Helm基础回顾

2. Helm 基础回顾：Chart 结构、Release 管理与核心命令详解

在生产窗口内执行 tc（流量控制）回滚验证之前，必须对 Helm 的核心概念与操作命令有扎实的理解。本节将系统回顾 Chart 的目录结构、Release 的生命周期管理，以及 install、upgrade、rollback 三个关键命令的用法与参数细节。

2.1 Chart 标准目录结构

一个 Helm Chart 是描述一组 Kubernetes 资源的文件集合。其标准结构如下：

mychart/
├── Chart.yaml          # Chart 元数据（名称、版本、描述等）
├── values.yaml         # 默认配置值
├── values.schema.json  # （可选）values 的 JSON Schema 校验文件
├── charts/             # （可选）子 Chart 依赖
├── crds/               # （可选）CustomResourceDefinition 定义
├── templates/          # Go 模板文件，渲染后生成 Kubernetes 资源清单
│   ├── NOTES.txt       # （可选）安装后的使用说明
│   ├── _helpers.tpl    # （可选）模板辅助函数
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ...
└── README.md           # （可选）使用文档

关键点： templates/ 目录下的文件使用 Go 模板语法，通过 values.yaml 注入变量。生产环境中，values.yaml 通常不直接修改，而是通过外部 --values 或 --set 参数覆盖。

2.2 Release 管理核心概念

Release 是 Helm 在目标 Kubernetes 集群中安装 Chart 后生成的一个运行实例。每个 Release 具有唯一的名称，并关联一个或多个 Revision（修订版本）。

概念	说明	生产窗口中的意义
Release	Chart 的一次部署实例，由名称标识	每个微服务对应一个 Release，便于独立管理
Revision	Release 的版本号，从 1 开始递增	回滚时指定 Revision 号，实现精确恢复
Status	Release 当前状态（deployed、failed、pending-install 等）	回滚前需确认当前 Release 状态为 deployed
History	Release 的所有 Revision 记录	通过 `helm history` 查看可回滚的目标版本

  生产实践： 建议在 values.yaml 中显式设置 revisionHistoryLimit（默认 10），控制保留的 Revision 数量，避免 etcd 存储膨胀。

2.3 Helm install / upgrade / rollback 命令详解

2.3.1 helm install — 首次部署

用于将 Chart 部署到集群，创建一个新的 Release。

# 基本语法
helm install [RELEASE_NAME] [CHART] [flags]

# 示例：部署 myapp Release，使用 values-prod.yaml 覆盖默认值
helm install myapp ./mychart \
  --namespace production \
  --values values-prod.yaml \
  --set image.tag=v1.0.0 \
  --atomic \
  --timeout 5m0s

参数	说明	生产建议
`--atomic`	如果安装失败则自动回滚	生产环境强烈建议启用
`--timeout`	等待操作完成的最大时间	根据服务启动时间合理设置，避免误判失败
`--wait`	等待所有 Pod 就绪	配合 `--atomic` 使用，确保部署完整性
`--dry-run`	模拟安装，不实际执行	变更前必须执行，验证模板渲染结果

2.3.2 helm upgrade — 滚动更新

用于升级已存在的 Release，支持增量变更。

# 基本语法
helm upgrade [RELEASE_NAME] [CHART] [flags]

# 示例：升级 myapp 到 v1.1.0，并启用新特性
helm upgrade myapp ./mychart \
  --namespace production \
  --reuse-values \
  --set image.tag=v1.1.0 \
  --set feature.enabled=true \
  --history-max 5 \
  --atomic \
  --timeout 10m0s

⚠️ 常见陷阱： --reuse-values 会复用上一次部署时的 values，但不会合并新传入的 --set 参数。推荐使用 --reset-values 或显式指定完整的 values 文件，避免配置漂移。

2.3.3 helm rollback — 回滚操作

将 Release 恢复到指定的历史 Revision。这是生产窗口内 tc 回滚验证的核心命令。

# 基本语法
helm rollback [RELEASE_NAME] [REVISION] [flags]

# 示例：将 myapp 回滚到 Revision 3
helm rollback myapp 3 \
  --namespace production \
  --atomic \
  --timeout 5m0s \
  --force \
  --wait

参数	说明	回滚场景下的作用
`--force`	强制替换资源，跳过某些校验	当资源无法正常更新时使用，慎用
`--cleanup-on-fail`	回滚失败时清理新创建的 Pod	避免残留资源影响后续操作
`--no-hooks`	跳过 pre/post 钩子	紧急回滚时可跳过钩子加速恢复
`--recreate-pods`	重建所有 Pod（非滚动更新）	当需要强制重启时使用

  回滚最佳实践： 在执行 helm rollback 前，先执行 helm history RELEASE_NAME -n NAMESPACE 确认目标 Revision 的状态为 deployed 或 superseded。避免回滚到 failed 状态的 Revision。

2.4 Helm 操作流程与状态转换

下图展示了 Helm 从安装到回滚的完整状态转换路径，帮助理解生产窗口内各阶段的操作位置。

2.5 生产窗口内回滚验证的 Helm 操作流程

结合 tc 回滚验证场景，推荐按以下步骤执行 Helm 操作：

预检查阶段：
- helm list -n production — 确认目标 Release 名称与状态
- helm history myapp -n production — 查看所有 Revision 及状态
- helm get values myapp -n production --revision N — 检查目标 Revision 的配置
回滚执行阶段：
- helm rollback myapp N -n production --atomic --timeout 5m0s --wait
- 观察回滚过程中的 Pod 状态变化
验证阶段：
- helm status myapp -n production — 确认 Release 状态为 deployed
- helm get manifest myapp -n production --revision N+1 — 验证新 Revision 的资源清单
- 结合 tc 工具验证网络拓扑与流量路径是否符合预期
异常处理：
- 若回滚超时或失败，使用 helm rollback --cleanup-on-fail 清理残留
- 紧急情况下使用 --no-hooks 跳过钩子加速回滚

生产窗口内建议： 在窗口开始前，提前通过 helm get manifest 导出当前 Revision 的完整资源清单作为基线。回滚后对比基线，确保网络策略、Service 端点、Ingress 规则等网络相关资源已正确恢复。