3. Helm 控制平面概述：Helm架构、Tiller（历史）与Helm 3无Tiller架构、控制平面组件
3.1 Helm 架构演进：从有状态到无状态
Helm 作为 Kubernetes 的包管理器，其控制平面架构经历了从 Client-Server（客户端-服务器） 到 纯客户端（Client-Only） 的重大演进。理解这一演进过程，是掌握 Helm 控制平面工作原理的关键。
核心要点： Helm 3 移除了服务端组件 Tiller，直接通过 Kubernetes API Server 与集群交互，消除了安全风险和状态管理复杂性。
3.2 Helm 2 架构：Tiller 时代
Helm 2 采用典型的 C/S 架构，由两个核心组件构成：
| 组件 | 角色 | 部署位置 | 核心职责 |
|---|---|---|---|
| Helm Client (helm CLI) | 客户端 | 用户本地机器或 CI/CD 环境 | Chart 打包、仓库管理、发布请求发送 |
| Tiller Server | 服务端 | Kubernetes 集群内部 (kube-system) | 接收请求、渲染模板、安装/升级/回滚、维护 Release 状态 |
Helm 2 的工作流程如下：
- 用户执行
helm install命令。 - Helm Client 将 Chart 和 Values 打包发送给 Tiller。
- Tiller 在服务端接收请求，结合 Chart 和 Values 渲染 Kubernetes 资源清单（YAML）。
- Tiller 通过调用 Kubernetes API 将资源清单应用到集群。
- Tiller 将 Release 的元数据（名称、版本、状态、配置等）存储在集群内的 ConfigMap 或 Secrets 中。
Helm 2 的痛点： Tiller 拥有过高的集群权限（通常为 cluster-admin），一旦被攻破，整个集群将面临风险。此外，Tiller 作为有状态服务，其自身的管理、升级和故障恢复也增加了运维复杂度。
3.3 Helm 3 架构：无 Tiller 时代
Helm 3 彻底移除了 Tiller 组件，将控制平面简化为 纯客户端架构。Helm Client 直接与 Kubernetes API Server 通信，不再需要中间服务端。
| 组件 | 角色 | 部署位置 | 核心职责 |
|---|---|---|---|
| Helm Client (helm CLI) | 唯一组件 | 用户本地机器或 CI/CD 环境 | Chart 打包、仓库管理、模板渲染、API 调用、Release 管理 |
| Kubernetes API Server | 目标系统 | Kubernetes 集群内部 | 接收 Helm Client 的请求，执行资源操作 |
Helm 3 的工作流程如下：
- 用户执行
helm install命令。 - Helm Client 在本地加载 Chart 和 Values，直接渲染 Kubernetes 资源清单（YAML）。
- Helm Client 使用本地 kubeconfig 文件中的凭据，直接调用 Kubernetes API Server。
- Kubernetes API Server 执行资源创建/更新操作。
- Helm Client 将 Release 元数据存储在集群内的 Secrets 中（默认命名空间）。
架构优势： 无 Tiller 架构消除了服务端单点故障和权限滥用风险，Helm Client 使用当前用户的 RBAC 权限，遵循最小权限原则，安全性大幅提升。
3.4 控制平面组件对比
下表从多个维度对比 Helm 2 与 Helm 3 的控制平面组件差异：
| 对比维度 | Helm 2 (Tiller) | Helm 3 (无 Tiller) |
|---|---|---|
| 架构模式 | Client-Server (C/S) | 纯客户端 (Client-Only) |
| 服务端组件 | Tiller (运行在集群内) | 无 |
| 权限模型 | Tiller 使用固定 ServiceAccount (通常为 cluster-admin) | 使用当前用户的 kubeconfig 凭据，遵循 RBAC |
| Release 存储 | ConfigMap 或 Secrets (默认 ConfigMap) | Secrets (默认，支持加密) |
| 模板渲染位置 | Tiller 服务端渲染 | Helm Client 本地渲染 |
| 安全性 | 较低 (Tiller 权限过高，易被攻击) | 较高 (用户权限隔离，无服务端暴露面) |
| 运维复杂度 | 较高 (需要管理 Tiller 的安装、升级、备份) | 较低 (无服务端组件，仅需管理 CLI) |
| Release 命名空间 | Tiller 所在命名空间 | 目标资源所在命名空间 |
3.5 Helm 3 控制平面核心组件详解
虽然 Helm 3 移除了 Tiller，但其控制平面仍然包含几个关键的逻辑组件，它们共同协作完成 Chart 的生命周期管理：
- Chart Loader：负责从本地文件系统或远程仓库加载 Chart 包，验证 Chart.yaml 的合法性，并解析依赖关系。
- Values Engine：负责合并多个 Values 来源（用户提供的 Values 文件、--set 参数、Chart 默认 values.yaml），生成最终的渲染参数集。
- Template Engine：使用 Go 模板引擎，将 Chart 中的模板文件与最终的 Values 结合，渲染出完整的 Kubernetes 资源清单（YAML）。
- Release Manager：管理 Release 的整个生命周期，包括安装、升级、回滚、卸载。它负责生成 Release 名称、版本号，并维护 Release 的历史记录。
- Kubernetes Client：封装了与 Kubernetes API Server 的交互逻辑，负责发送创建、更新、删除资源的请求，并处理 API 响应。
- Storage Backend：负责将 Release 元数据持久化到 Kubernetes Secrets 中，支持加密存储，确保 Release 信息的安全性和可追溯性。
关键理解： Helm 3 的控制平面本质上是将 Helm 2 中 Tiller 的职责（模板渲染、Release 管理、API 调用）全部移到了 Helm Client 本地执行，同时利用 Kubernetes 自身的 RBAC 和 Secrets 机制来保证安全性和持久化。这使得 Helm 3 更加轻量、安全、易于集成到 CI/CD 流水线中。