📚 课程目录第1章 Helm整体架构概述

1. Helm 整体架构概述

Helm 是 Kubernetes 生态中最流行的包管理器，其核心职责是将应用打包为 Chart，并通过模板引擎渲染为 Kubernetes 可识别的 YAML 清单。理解 Helm 的架构演进与组件职责划分，是掌握控制平面与 Chart 仓库数据传输设计的前提。

Helm v3 最重大的架构变更是从客户端-服务端模式（v2）转变为纯客户端模式（v3），移除了集群内的 Tiller 组件。下表从多个维度对比两个版本的架构差异：

对比维度	Helm v2（含 Tiller）	Helm v3（无 Tiller）
架构模式	客户端（CLI）+ 服务端（Tiller）	纯客户端（CLI）
Tiller 角色	运行在集群内，负责接收 CLI 请求、渲染 Chart、执行安装/升级/删除	已移除，所有操作由 Helm CLI 直接通过 Kubernetes API 完成
权限模型	Tiller 拥有集群级 ServiceAccount，存在安全风险	使用用户当前的 kubeconfig 权限，遵循最小权限原则
Release 存储	Tiller 将 Release 信息存储在集群内的 ConfigMap 中	Helm CLI 将 Release 信息存储在集群内的 Secret 中（默认）
Chart 渲染位置	服务端（Tiller 内完成模板渲染）	客户端（Helm CLI 本地完成模板渲染）
网络依赖	CLI 需与 Tiller 建立 gRPC 连接	CLI 直接与 Kubernetes API Server 通信
多租户支持	困难，Tiller 共享一个 ServiceAccount	原生支持，每个用户使用独立凭据

  架构演进要点： Helm v3 通过移除 Tiller，消除了集群内的特权服务端组件，将安全模型对齐到 Kubernetes RBAC，同时简化了部署流程。所有 Chart 渲染逻辑移至客户端，使得控制平面与数据平面的交互路径更加清晰。

在 Helm 架构中，控制平面与数据平面的职责边界清晰，二者通过标准化的 HTTP/HTTPS 协议进行 Chart 包的分发与同步。

Chart 管理： 负责 Chart 的本地打包（helm package）、依赖解析（helm dependency）、模板渲染与验证。
Release 生命周期： 执行安装（helm install）、升级（helm upgrade）、回滚（helm rollback）、卸载（helm uninstall）等操作。
仓库索引管理： 维护本地仓库缓存（helm repo update），解析 Chart 版本与依赖关系。
安全与认证： 处理 Chart 签名验证（Provenance）、仓库认证（Basic Auth / OAuth / TLS）。
与 Kubernetes API 交互： 将渲染后的 YAML 清单提交给 API Server，并监控部署状态。

职责边界提示： 控制平面负责“如何部署”与“部署什么”，数据平面负责“存储什么”与“提供什么”。Helm CLI 从不直接修改仓库中的 Chart 文件，仓库也从不参与模板渲染或 Release 管理。这种松耦合设计使得 Chart 仓库可以独立扩展、镜像或迁移。

一次典型的 Chart 安装操作，完整展示了控制平面与数据平面的协作过程：

注意： 在 Helm v3 中，Chart 包下载后仅在客户端内存或临时目录中存在，不会持久化到集群内。每次 helm install 或 helm upgrade 都会重新从仓库拉取 Chart（除非使用本地路径）。因此，Chart 仓库的可用性与响应速度直接影响部署效率。