3. Helm 工作原理：Chart 结构、Tiller/Helm v3 架构差异、Release 管理机制
理解 Helm 的工作原理是掌握故障域隔离设计的前提。本章深入剖析 Helm 的核心组件：Chart 的目录与文件规范、Helm v2 (Tiller) 与 Helm v3 的架构演进，以及 Release 版本的生命周期管理机制。
3.1 Chart 结构：应用包的标准规范
一个 Helm Chart 是描述一组 Kubernetes 资源的文件集合。遵循标准目录结构，确保 Chart 可被 Helm 客户端解析、验证与渲染。
3.1.1 标准目录布局
mychart/
├── Chart.yaml # Chart 元数据（名称、版本、API版本等）
├── values.yaml # 默认配置值
├── values.schema.json # (可选) values 的 JSON Schema 校验
├── charts/ # (可选) 子 Chart 依赖（.tgz 或目录）
├── crds/ # (可选) 自定义资源定义（CRD）
├── templates/ # 模板文件目录
│ ├── NOTES.txt # (可选) 安装后的使用说明
│ ├── _helpers.tpl # (可选) 模板辅助函数
│ ├── deployment.yaml
│ ├── service.yaml
│ └── ...
└── README.md # (可选) 使用文档3.1.2 核心文件职责
| 文件/目录 | 职责 | 是否必须 |
|---|---|---|
Chart.yaml |
定义 Chart 名称、版本、API 版本、描述、关键字等 | 是 |
values.yaml |
提供默认配置值，模板通过 .Values 引用 |
是 |
templates/ |
存放 Go 模板文件，渲染后生成 Kubernetes 资源清单 | 是 |
charts/ |
管理子 Chart 依赖，支持嵌套依赖树 | 否 |
crds/ |
存放 CRD 定义，Helm v3 在安装时优先应用 | 否 |
最佳实践： 在
values.yaml 中为所有可配置项提供默认值，并使用 values.schema.json 对用户输入进行校验，避免因配置错误导致故障域扩大。
3.2 Tiller vs Helm v3：架构演进与故障域影响
Helm v2 与 v3 最核心的差异在于 服务端组件 Tiller 的移除。这一变化直接影响了权限模型、安全边界以及故障隔离能力。
3.2.1 架构对比
| 维度 | Helm v2 (Tiller) | Helm v3 (无 Tiller) |
|---|---|---|
| 服务端组件 | Tiller 运行在集群内，拥有集群管理员权限 | 无服务端组件，仅 Helm 客户端与 API Server 交互 |
| 权限模型 | Tiller 使用 ServiceAccount，权限过大，存在安全风险 | 客户端使用 kubeconfig 中的用户权限，遵循 RBAC |
| Release 存储 | 存储在集群内的 ConfigMap 中（默认命名空间） | 存储在集群内的 Secret 中（Release 所在命名空间） |
| 故障域影响 | Tiller 单点故障，影响所有 Release 管理 | 无中心组件，故障域缩小到客户端与 API Server 连接 |
| 安全隔离 | Tiller 可访问所有命名空间，隔离性差 | 客户端权限受 kubeconfig 限制，天然支持多租户隔离 |
故障域关键点： Helm v2 的 Tiller 是一个集群级别的单点故障组件。一旦 Tiller 崩溃或被攻击，所有通过 Helm 管理的 Release 都无法进行安装、升级或回滚操作。Helm v3 移除了 Tiller，将故障域缩小到客户端与 API Server 之间的通信链路，显著提升了控制平面的稳定性。
3.2.2 架构演进示意图
3.3 Release 管理机制
Release 是 Helm 管理的核心抽象，代表 Chart 的一次部署实例。Helm 通过版本号、状态和存储后端来管理 Release 的完整生命周期。
3.3.1 Release 生命周期状态机
| 状态 | 描述 | 触发操作 |
|---|---|---|
pending-install |
安装请求已提交，资源尚未完全创建 | helm install |
deployed |
Release 已成功部署并运行 | helm install / helm upgrade 成功 |
failed |
安装或升级过程中发生错误 | 操作执行失败 |
pending-upgrade |
升级请求已提交，资源正在更新 | helm upgrade |
pending-rollback |
回滚请求已提交，资源正在恢复 | helm rollback |
superseded |
旧版本 Release，已被新版本替代 | helm upgrade / helm rollback 后 |
uninstalled |
Release 已被卸载，但历史记录保留 | helm uninstall |
uninstalling |
卸载请求已提交，资源正在清理 | helm uninstall |
3.3.2 Release 版本管理
每次 helm upgrade 或 helm rollback 都会创建一个新的 Release 版本。Helm v3 默认保留最近 10 个 历史版本（可通过 --history-max 配置）。
# 查看 Release 历史版本
helm history my-release -n my-namespace
# 输出示例
REVISION STATUS CHART APP VERSION DESCRIPTION
1 superseded mychart-1.0.0 1.0 Install complete
2 superseded mychart-1.1.0 1.1 Upgrade complete
3 deployed mychart-1.2.0 1.2 Upgrade complete3.3.3 Release 存储与故障域
Helm v3 将 Release 信息存储在 Secret 中，且位于 Release 所在的命名空间。这一设计对故障域隔离至关重要：
- 命名空间隔离： 每个 Release 的 Secret 只存在于其所属命名空间，不会跨命名空间泄露。
- 权限最小化： 客户端只需对目标命名空间具有读写 Secret 的权限，无需集群级权限。
- 故障域缩小： 某个命名空间的 Release 管理故障不会影响其他命名空间。
关键结论： Helm v3 通过移除 Tiller、使用 Secret 存储 Release、以及遵循 RBAC 权限模型，将故障域从“集群级”缩小到“命名空间级”。在后续章节中，我们将利用这一特性设计 DNS 故障隔离与控制平面隔离策略。
3.4 本章小结
- Chart 结构： 标准化的目录与文件规范，确保应用包的可移植性与可维护性。
- 架构演进： Helm v3 移除 Tiller，消除了集群级单点故障，提升了安全性与故障隔离能力。
- Release 管理： 基于 Secret 的版本化存储，支持回滚、历史追溯，且故障域限定在命名空间内。