1. Helm 基础回顾：架构、Chart 结构、Release 生命周期与 Tiller/Helm3 差异
1.1 Helm 整体架构
Helm 是 Kubernetes 生态中最流行的包管理工具，其核心职责是将应用及其依赖打包为 Chart，并通过模板引擎在目标集群中生成可重复部署的 Kubernetes 资源清单。理解 Helm 架构是故障追踪的第一步。
架构要点： Helm 采用客户端-运行时架构。Helm 3 移除了服务端组件 Tiller，改为直接通过 Kubernetes API Server 与集群交互，大幅简化了安全模型与故障域。
1.2 Chart 结构详解
一个标准的 Helm Chart 是一个遵循特定目录结构的文件集合。故障排查时，80% 的问题根源隐藏在 Chart 结构或模板渲染逻辑中。
| 文件/目录 | 是否必需 | 作用说明 |
|---|---|---|
Chart.yaml |
是 | Chart 元数据：名称、版本、apiVersion、描述、依赖声明 |
values.yaml |
是 | 默认配置值，模板渲染时的变量来源 |
templates/ |
是 | Go 模板文件目录，最终生成 Kubernetes 资源清单 |
charts/ |
否 | 子 Chart 依赖目录（手动或 helm dependency update 生成） |
crds/ |
否 | 自定义资源定义（CRD），在模板渲染前安装 |
templates/NOTES.txt |
否 | 安装成功后输出的使用说明文本 |
templates/tests/ |
否 | Helm Test 使用的 Pod 模板，用于验证 Release 是否正常 |
故障追踪提示： 当 Release 部署失败时，优先检查
templates/ 目录下的模板语法是否正确，以及 values.yaml 中是否遗漏了必需的配置项。使用 helm template 命令可以在不实际部署的情况下预览渲染后的 YAML。
1.3 Release 生命周期
Release 是 Helm 管理的核心概念，代表 Chart 的一次部署实例。每个 Release 都有明确的 状态 和 修订版本号，这是故障域追踪的关键路径。
1.4 Tiller vs Helm 3：关键差异对比
Helm 2 中的 Tiller 组件是许多安全故障和权限问题的根源。Helm 3 彻底移除了 Tiller，这是 Helm 历史上最重要的架构变更。以下表格总结了核心差异：
| 对比维度 | Helm 2 (Tiller) | Helm 3 (无 Tiller) |
|---|---|---|
| 架构组件 | Client + Tiller (服务端) | Client 直连 API Server |
| 安全模型 | Tiller 拥有集群级权限，存在提权风险 | 使用 kubeconfig 的当前用户权限，遵循 RBAC |
| Release 信息存储 | 存储在集群内的 ConfigMap 中（默认命名空间） | 存储在集群内的 Secret 中（Release 所在命名空间） |
| CRD 管理 | 需要手动或通过 hook 管理 | 支持 crds/ 目录自动安装 CRD |
| 依赖管理 | 通过 requirements.yaml 声明 |
合并到 Chart.yaml 的 dependencies 字段 |
| 命名空间作用域 | Tiller 自身有命名空间，Release 可跨命名空间 | Release 严格绑定到当前命名空间 |
| helm init | 需要执行 helm init 安装 Tiller |
无需初始化，直接使用 |
| 故障排查复杂度 | 高（Tiller 日志、Tiller 权限、Tiller 版本兼容性） | 低（直接使用 kubectl 和 kubeconfig 排查） |
迁移警告： 如果你仍在使用 Helm 2，请尽快迁移到 Helm 3。Helm 2 已于 2020 年 11 月停止安全更新。迁移时注意 Release 数据迁移（
helm 2to3 插件）以及 Chart 中 apiVersion 的变更。
1.5 关键命令速查表
以下命令是 Helm 故障域追踪的基石，建议熟练掌握：
# 查看所有 Release（包括失败和卸载的）
helm list --all-namespaces --all
# 查看 Release 详细信息（状态、修订版本、资源清单）
helm status RELEASE_NAME -n NAMESPACE
# 查看 Release 的修订历史
helm history RELEASE_NAME -n NAMESPACE
# 回滚到指定修订版本
helm rollback RELEASE_NAME REVISION -n NAMESPACE
# 预览模板渲染结果（不实际部署）
helm template RELEASE_NAME ./chart-dir -f custom-values.yaml
# 调试 Chart 渲染过程
helm install RELEASE_NAME ./chart-dir --dry-run --debug
# 获取已部署 Release 的 values 值
helm get values RELEASE_NAME -n NAMESPACE
# 获取已部署 Release 的模板清单
helm get manifest RELEASE_NAME -n NAMESPACE
实战建议： 在排查故障时，
helm get manifest 和 helm get values 是最常用的两个命令。前者可以查看集群中实际应用的资源清单，后者可以查看最终生效的配置值，两者结合可以快速定位“配置漂移”或“模板渲染错误”问题。