📚 课程目录第2章 Helm核心概念回顾

2. Helm 核心概念回顾：Chart、Release、Repository、Values、Templates、Hooks

在深入回滚策略设计之前，必须重新校准 Helm 的六大核心概念。这些概念不仅是 Helm 的操作基础，更是回滚机制能够精准定位、恢复和审计的底层支撑。以下从回滚视角重新解读每个概念。

2.1 概念总览与回滚关联

概念	定义	回滚中的关键作用
Chart	Kubernetes 资源的打包模板集合	回滚时需确认 Chart 版本是否兼容目标集群
Release	Chart 在集群中的一次部署实例	回滚操作本质是创建新的 Release 版本
Repository	Chart 的存储与分发仓库	回滚依赖历史 Chart 版本的可追溯性
Values	Chart 的运行时配置参数	回滚时必须恢复对应版本的 Values 快照
Templates	Go 模板引擎渲染的 Kubernetes 清单	回滚后重新渲染旧模板，确保资源一致性
Hooks	Release 生命周期中的干预点	回滚前后执行清理、迁移、验证等自动化任务

回滚视角提示： Helm 的回滚并非“撤销”操作，而是基于历史 Release 版本重新创建一次部署。这意味着每次回滚都会产生一个新的 Release 版本号，历史版本链始终保持完整。

2.2 Chart：应用的打包单元

Chart 是 Helm 的核心制品，包含运行一个应用所需的所有 Kubernetes 资源定义。一个标准 Chart 的目录结构如下：

mychart/
├── Chart.yaml          # Chart 元数据（名称、版本、API 版本）
├── values.yaml         # 默认配置值
├── values.schema.json  # （可选）Values 的 JSON Schema 校验
├── charts/             # 子 Chart 依赖
├── templates/          # Go 模板文件
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl    # 模板辅助函数
└── templates/tests/    # 测试模板

在回滚场景中，Chart 的 version 字段至关重要。如果回滚目标版本的 Chart 与当前集群的 CRD 版本或 API 版本不兼容，回滚将失败。因此，回滚策略必须包含 Chart 版本兼容性检查。

2.3 Release：部署实例与版本链

Release 是 Chart 在 Kubernetes 集群中的一次具体部署。每次 helm install、helm upgrade 或 helm rollback 都会生成一个新的 Release 版本。Helm 使用 Secret（默认）或 ConfigMap 在 kube-system 命名空间中存储 Release 历史。

# 查看 Release 历史版本
helm history my-release

REVISION    UPDATED                     STATUS          CHART             APP VERSION    DESCRIPTION
1           Mon Jan 15 10:00:00 2024    superseded      myapp-1.0.0       1.0.0          Install complete
2           Mon Jan 15 11:00:00 2024    deployed        myapp-1.1.0       1.1.0          Upgrade complete
3           Mon Jan 15 12:00:00 2024    superseded      myapp-1.1.0       1.1.0          Rollback to 1

关键约束： Helm 默认保留最近 10 个 Release 版本。如果回滚目标版本已被删除，则无法直接回滚。生产环境建议通过 --history-max 参数增加保留数量，或使用外部存储备份 Release 历史。

2.4 Repository：Chart 的版本仓库

Repository 是 Chart 的远程存储和分发中心。回滚操作通常需要从 Repository 获取历史 Chart 版本。Helm 支持 OCI 和传统 Chart 仓库两种格式。

仓库类型	版本管理方式	回滚优势	回滚风险
传统 Chart 仓库	index.yaml 索引文件	简单直接，支持语义化版本	版本覆盖后无法恢复
OCI 仓库	容器镜像标签 + Digest	不可变版本，Digest 保证一致性	需要 OCI 兼容的 Registry

  最佳实践： 在回滚策略中，优先使用 OCI 仓库。因为 OCI 的 Digest 机制确保回滚时拉取的 Chart 内容与原始部署完全一致，避免因 Chart 版本被覆盖导致的“回滚到错误版本”问题。

2.5 Values：配置参数与回滚快照

Values 是 Chart 的运行时配置。每次 Release 都会保存一份完整的 Values 快照。回滚时，Helm 默认使用目标版本的 Values，但也可以覆盖。

# 查看指定版本的 Values
helm get values my-release --revision 1

# 回滚时使用自定义 Values（覆盖历史版本）
helm rollback my-release 1 --set replicaCount=5

回滚策略必须考虑 Values 的三种状态：

历史 Values： 回滚目标版本保存的原始配置
当前 Values： 当前 Release 正在使用的配置
覆盖 Values： 回滚时通过 --set 或 -f 传入的新配置

回滚决策点： 当回滚是由于配置错误导致时，应使用历史 Values；当回滚是由于代码缺陷导致时，可能需要保留当前 Values 并仅回滚 Chart 模板。策略设计需要区分这两种场景。

2.6 Templates：资源清单的渲染引擎

Templates 使用 Go 模板语法将 Chart 中的 Kubernetes 资源定义与 Values 结合，生成最终的 YAML 清单。回滚时，Helm 会重新渲染目标版本的 Templates + Values。

# 渲染指定版本的模板（不实际部署）
helm template my-release --revision 1

# 输出示例（简化）
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-release-myapp
spec:
  replicas: {{ .Values.replicaCount }}  # 渲染为 3
  template:
    spec:
      containers:
      - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

回滚的可靠性取决于模板渲染的可重复性。如果模板中使用了非确定性函数（如 now、randAlphaNum），回滚后的资源可能与原始版本存在差异。回滚策略应避免在模板中使用此类函数，或通过 Hooks 进行后处理修正。

2.7 Hooks：生命周期中的自动化干预点

Hooks 允许在 Release 生命周期的特定时刻执行 Pod 任务。回滚场景中，Hooks 可用于数据迁移、缓存预热、健康检查等自动化操作。

Hook 类型	触发时机	回滚中的典型用途
pre-rollback	回滚开始前	备份当前数据库、锁定写入操作
post-rollback	回滚完成后	验证服务健康、清理临时资源
pre-upgrade	升级开始前	回滚场景中不直接使用，但影响版本链
post-upgrade	升级完成后	回滚场景中不直接使用，但影响版本链

Hook 失败处理： 默认情况下，如果 pre-rollback Hook 执行失败，回滚操作会中止。post-rollback Hook 失败则不会阻止回滚，但会在 Release 状态中标记警告。策略设计时应为关键 Hook 添加重试机制和超时控制。

2.8 核心概念关系图

下图展示了六大概念在 Helm 回滚流程中的协作关系：

2.9 回滚视角下的概念总结

从回滚策略设计的角度，六个核心概念可以归纳为三个层次：

制品层（Chart + Repository）： 保证回滚目标的可获取性和版本一致性
运行时层（Release + Values + Templates）： 保证回滚过程的正确性和可重复性
自动化层（Hooks）： 保证回滚前后的业务连续性和数据完整性