2. Helm 基础回顾：Helm 架构、Chart 结构、Release 概念、Helm install/upgrade/rollback 核心流程
在深入探讨发布一致性校验之前，有必要重新梳理 Helm 的核心基础。Helm 作为 Kubernetes 的包管理器，其设计围绕三个核心概念展开：Chart（应用定义）、Release（运行实例）和 Repository（仓库）。理解这三者之间的关系以及 Helm 的运行时架构，是后续进行内容对比与配置漂移检测的前提。
2.1 Helm 架构概览
Helm 采用客户端-服务器架构。客户端是 Helm CLI，负责本地 Chart 开发、打包和发布管理；服务端是 Tiller（Helm 2）或通过 Helm SDK 直接与 Kubernetes API 交互（Helm 3）。Helm 3 移除了 Tiller，提升了安全性和架构简洁性。
版本提示：本课程基于 Helm 3。Helm 3 不再需要服务端组件 Tiller，直接通过 kubeconfig 文件与 Kubernetes API Server 通信，每个 Release 的元数据以 Secret 资源存储在目标命名空间中。
2.2 Chart 结构详解
Chart 是 Helm 应用的定义包，遵循标准化的目录结构。一个完整的 Chart 包含描述文件、模板文件、默认值以及依赖声明。
| 文件/目录 | 必需 | 说明 |
|---|---|---|
Chart.yaml |
是 | Chart 元数据：名称、版本、API 版本、描述、类型（application/library） |
values.yaml |
是 | 默认配置值，模板渲染时的输入参数 |
templates/ |
是 | Go 模板文件目录，渲染后生成 Kubernetes 资源清单 |
charts/ |
否 | 子 Chart 依赖（手动或通过 helm dependency 管理） |
crds/ |
否 | 自定义资源定义（CRD），在模板渲染前安装 |
templates/NOTES.txt |
否 | 安装成功后显示的使用说明文本 |
templates/tests/ |
否 | 测试 Pod 模板，用于验证 Release 是否正常运行 |
关键点：模板引擎使用 Go 模板语法（
{{ .Values.replicaCount }}），结合 values.yaml 和用户提供的 --set 或 -f 参数进行渲染。模板中还可以使用 include、required、default 等函数实现逻辑控制。
2.3 Release 概念
Release 是 Chart 在 Kubernetes 集群中的一个运行实例。每次执行 helm install 都会创建一个新的 Release；每次执行 helm upgrade 都会生成一个新的 Release 修订版本（Revision）。
| 概念 | 说明 |
|---|---|
| Release Name | 用户指定的实例名称，在命名空间内唯一 |
| Revision | 每次 upgrade 递增的版本号，从 1 开始 |
| Release Status | deployed / failed / pending-install / superseded / uninstalled |
| Release Secret | 存储 Release 元数据和渲染后的清单，命名格式：sh.helm.release.v1.<name>.v<revision> |
配置漂移风险：Release 的元数据（包括 values 和渲染后的模板）存储在 Secret 中。如果用户通过
kubectl edit 直接修改了集群中的资源（如 Deployment），而 Helm 的 Secret 中记录的仍是旧配置，就会产生配置漂移。这正是本课程后续要重点检测的场景。
2.4 Helm install / upgrade / rollback 核心流程
这三个命令构成了 Helm 发布管理的生命周期。理解它们的内部步骤，有助于定位一致性校验的切入点。
2.4.1 helm install 流程
- 加载 Chart：从本地路径或仓库加载 Chart 包，解析
Chart.yaml和依赖。 - 合并 Values：将
values.yaml、用户提供的-f文件、--set参数按优先级合并。 - 模板渲染：使用合并后的 Values 渲染
templates/目录下的所有 Go 模板文件。 - 校验清单：对渲染后的 Kubernetes 资源清单进行语法和 schema 校验（如
helm lint规则）。 - 创建 Release：在目标命名空间中创建 Release Secret（revision=1），状态为
pending-install。 - 应用资源：通过 Kubernetes API 依次创建资源（按 Kind 顺序：Namespace、CRD、Resource 等）。
- 更新状态：如果所有资源创建成功，将 Release 状态更新为
deployed；否则标记为failed。
2.4.2 helm upgrade 流程
- 加载并渲染：与 install 相同，加载 Chart 并渲染新版本的模板。
- 计算 Diff：将新渲染的清单与当前 Release 的 Secret 中记录的旧清单进行对比（3-way strategic merge patch）。
- 创建新 Revision：生成新的 Release Secret（revision 递增），状态为
pending-upgrade。 - 执行更新：对变更的资源执行
kubectl apply（或 patch/delete 操作）。 - 更新状态：成功则标记新 Revision 为
deployed，旧 Revision 标记为superseded。
2.4.3 helm rollback 流程
- 获取目标 Revision：根据用户指定的版本号，从 Release Secret 中读取对应的旧清单。
- 回滚操作：将集群中的资源恢复到目标 Revision 所定义的配置状态。
- 创建新 Revision：回滚不会覆盖历史，而是创建一个新的 Revision（内容与目标 Revision 相同），状态为
deployed。 - 更新状态：被回滚的 Revision 标记为
superseded。
一致性校验切入点：在
helm upgrade 的“计算 Diff”步骤中，Helm 默认只对比当前 Release Secret 中的清单与新渲染清单。如果集群资源被外部修改（配置漂移），Helm 可能无法感知。本课程后续将介绍如何通过 helm get manifest 和 helm get values 获取“期望状态”，再与集群实际状态进行对比，从而检测漂移。
2.5 核心命令速查
| 命令 | 用途 | 常用参数 |
|---|---|---|
helm install <name> <chart> |
安装新 Release | --namespace, --set, -f, --create-namespace |
helm upgrade <name> <chart> |
升级已有 Release | --install（不存在则安装）, --reset-values, --reuse-values |
helm rollback <name> <revision> |
回滚到指定版本 | --cleanup-on-fail, --force |
helm list |
列出 Release | --namespace, --all-namespaces, --deployed |
helm get manifest <name> |
获取 Release 的期望清单 | --revision |
helm get values <name> |
获取 Release 的 values | --revision, --all |
实践建议：在制作一致性校验工具时，
helm get manifest 和 helm get values 是最重要的两个命令。它们能精确获取 Helm 认为集群“应该是什么样”，是后续与集群实际状态对比的基准线。