1.1 Helm 概述
Helm 是 Kubernetes 生态中事实上的包管理标准，类比操作系统中的 apt/yum 或编程语言中的 npm/pip。它通过“Chart”这一标准化打包格式，将 Kubernetes 资源（Deployment、Service、ConfigMap 等）组合、参数化并统一管理，让应用交付从“手动拼 YAML”升级为“一键安装/升级/回滚”。
Helm 的核心价值
- 标准化打包：Chart 定义了一套目录结构和模板语法，团队之间可以复用、共享、版本化应用定义。
- 参数化与环境隔离：通过 values.yaml 和模板引擎，同一套 Chart 可生成 dev/staging/prod 不同配置，无需复制 YAML。
- 声明式生命周期：Helm 管理 Release（一次部署实例），支持 install、upgrade、rollback、uninstall 等原子操作。
- 依赖与仓库管理：Chart 可以依赖其他 Chart，通过 Helm Repo 分发，类似 Docker Hub 之于容器镜像。
- 降低运维心智负担：团队无需记忆每个微服务的 YAML 细节，只需维护 Chart 和 values 即可。
Helm 与 Kubernetes 的关系
| 维度 | Kubernetes | Helm |
|---|---|---|
| 定位 | 容器编排平台 | K8s 应用包管理器 |
| 操作对象 | Pod、Service、Deployment 等原生资源 | Chart（打包后的 K8s 资源模板） |
| 部署方式 | kubectl apply -f 逐个 YAML | helm install / upgrade 一次操作 |
| 版本管理 | 依赖外部 Git 或 CI 记录 | 内置 Release 版本追踪与回滚 |
| 参数化 | 需手动 sed 或 Kustomize | 模板引擎 + values.yaml 原生支持 |
一句话总结：Kubernetes 提供了基础设施抽象层，Helm 在此基础上提供了应用交付抽象层。两者配合，让“声明式基础设施”真正延伸到“声明式应用交付”。
Helm 版本演进：v2 vs v3
Helm v2 于 2016 年发布，引入了 Chart 和 Release 概念，但架构上依赖集群内的 Tiller 服务端组件。Tiller 拥有集群级权限，负责接收客户端请求并渲染安装资源。这一设计带来了安全与运维上的痛点。
Helm v3 于 2019 年发布，彻底移除了 Tiller，客户端直接通过 kubeconfig 与 Kubernetes API Server 交互。v3 还引入了 Release 存储在集群内（Secret）、Chart 库支持 OCI 镜像、JSON Schema 校验等关键改进。
| 对比项 | Helm v2 | Helm v3 |
|---|---|---|
| 服务端组件 | Tiller（需部署在集群内） | 无（纯客户端） |
| 权限模型 | Tiller 拥有集群级 RBAC | 继承 kubeconfig 用户权限 |
| Release 存储 | ConfigMap（默认命名空间） | Secret（可配置为 ConfigMap） |
| Chart 分发 | 仅 HTTP/HTTPS Repo | Repo + OCI 镜像仓库 |
| 命名空间隔离 | Release 名称全局唯一 | Release 名称按命名空间隔离 |
| JSON Schema | 不支持 | 支持 values 校验 |
| Library Chart | 不支持 | 支持（仅模板，无资源） |
迁移提醒：Helm v2 已于 2020 年 11 月停止安全更新，所有仍在生产环境使用 v2 的团队应尽快迁移至 v3。迁移工具
helm-2to3 可帮助将 v2 Release 转换为 v3 格式。
学习建议：本课程所有实战操作均基于 Helm v3。如果你所在团队仍在使用 v2，建议先使用
helm 2to3 工具完成迁移，再跟随课程进行后续学习。