1. Helm 基础：Helm 的起源、Helm v3 架构、Chart 包结构、Tiller 移除后的安全模型
1.1 Helm 的起源与演进
Helm 最初由 Deis 公司在 2015 年发起，旨在解决 Kubernetes 应用打包、版本管理和部署的标准化问题。2016 年，Helm 被捐赠给 CNCF，并于 2018 年正式毕业，成为云原生生态中事实上的包管理标准。Helm 的核心价值在于将 Kubernetes 资源清单（YAML）抽象为可配置、可复用、可版本化的 Chart 包，从而大幅降低应用交付的复杂度。
| 版本 | 发布时间 | 核心架构 | 关键变化 |
|---|---|---|---|
| Helm v2 | 2016 | 客户端 + 服务端 Tiller | 引入 Chart 概念，Tiller 负责集群内资源管理 |
| Helm v3 | 2019 | 纯客户端架构 | 移除 Tiller，引入 Release 记录存储于集群，增强安全模型 |
关键认知：Helm v3 的架构变革并非简单的功能升级，而是对 Kubernetes 安全模型的一次根本性对齐。移除 Tiller 意味着不再需要集群内的高权限服务端组件，所有操作由客户端直接通过 kubeconfig 与 API Server 交互，权限控制回归到 Kubernetes RBAC 体系。
1.2 Helm v3 架构剖析
Helm v3 采用纯客户端架构，核心组件包括 Helm CLI、Chart 包、Release 记录和 Kubernetes API Server。客户端直接通过 kubeconfig 文件与 API Server 通信，不再依赖集群内的 Tiller 服务端。
架构要点：
- Helm CLI：负责 Chart 的打包、依赖解析、模板渲染和部署执行。
- Chart 包：标准化的应用打包格式，包含模板、默认值和依赖定义。
- kubeconfig：客户端认证凭据，决定操作权限和作用域。
- Release 记录：每次部署生成一个 Release，状态信息存储在目标命名空间的 Secret 或 ConfigMap 中。
1.3 Chart 包结构详解
一个标准的 Helm Chart 包遵循固定的目录结构，每个文件和目录都有明确的语义。理解 Chart 结构是编写高质量 Helm 包的基础。
my-chart/
├── Chart.yaml # Chart 元数据：名称、版本、描述、依赖
├── values.yaml # 默认配置值，供模板引用
├── values.schema.json # (可选) values.yaml 的 JSON Schema 校验
├── charts/ # (可选) 子 Chart 依赖包
│ └── sub-chart-1.0.0.tgz
├── templates/ # 核心模板目录
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── _helpers.tpl # 模板辅助函数
│ └── NOTES.txt # 部署后提示信息
├── crds/ # (可选) 自定义资源定义
│ └── my-crd.yaml
└── README.md # 使用说明| 文件/目录 | 必选 | 功能说明 |
|---|---|---|
| Chart.yaml | 是 | 定义 Chart 名称、版本、API 版本、描述、关键字、依赖列表 |
| values.yaml | 是 | 提供默认配置值，模板通过 .Values 对象引用 |
| templates/ | 是 | 存放 Go 模板文件，渲染后生成 Kubernetes 资源清单 |
| charts/ | 否 | 存放子 Chart 依赖包，Helm 会自动解压和合并 |
| crds/ | 否 | 存放 CRD 定义，Helm 在安装时优先创建 CRD |
| values.schema.json | 否 | 对 values.yaml 进行结构化校验，防止配置错误 |
常见陷阱：templates/ 目录下的所有 YAML 文件都会被 Helm 渲染并提交给 Kubernetes API Server。如果模板中存在语法错误或未定义的变量引用，会导致整个 Release 安装失败。建议在开发阶段使用
helm lint 和 helm template --debug 进行预检。
1.4 Tiller 移除后的安全模型
Helm v2 的 Tiller 组件是集群内的高权限服务端进程，拥有对 Kubernetes API 的广泛访问权限。这种设计带来了严重的安全隐患：Tiller 的 ServiceAccount 往往被授予 cluster-admin 角色，任何能访问 Tiller 的用户都能间接获得集群管理权限。Helm v3 彻底移除了 Tiller，将安全模型重构为基于 kubeconfig 的客户端认证体系。
安全模型核心变化：
- 权限隔离：每个用户使用自己的 kubeconfig 和 ServiceAccount，权限范围由 Kubernetes RBAC 精确控制。
- 无集群内服务端：不再需要维护 Tiller 的 ServiceAccount、ClusterRoleBinding 和 Deployment，攻击面大幅缩小。
- Release 记录本地化：Release 状态存储在目标命名空间的 Secret 中，默认使用
ownerReferences关联资源，避免跨命名空间权限泄露。 - 插件与认证分离：Helm 插件不再拥有隐式集群权限，所有操作必须通过 kubeconfig 认证。
生产建议：在 Helm v3 环境中，推荐为每个团队或每个应用创建独立的命名空间和 ServiceAccount，并通过 RBAC 限制其只能操作本命名空间内的资源。对于跨命名空间的操作（如安装 ClusterRole），必须显式授予对应的 ClusterRoleBinding 权限。