1. Helm 基础回顾：架构、Chart 结构与核心概念
在深入多集群 Chart 仓库配置与迁移之前，必须重新夯实 Helm 的基础知识。本章从架构演进、Chart 结构、Tiller 到 Helm 3 的变化以及核心概念四个维度展开，为后续实战建立统一认知。
1.1 Helm 架构演进：从 Client-Only 到无 Tiller
Helm 的架构经历了从 Helm 2（客户端 + 服务端 Tiller）到 Helm 3（纯客户端）的重大变革。下图展示了两种架构的核心差异：
架构演进要点：
- Helm 2：客户端 + 服务端 Tiller，Tiller 在集群内运行，负责 Chart 安装、升级、回滚。
- Helm 3：纯客户端架构，直接通过 Kubernetes API 与集群交互，不再需要 Tiller。
- 安全提升：Helm 3 使用 Kubernetes RBAC 进行权限控制，避免了 Tiller 的超级管理员风险。
1.2 Chart 结构详解
Chart 是 Helm 的打包格式，本质是一个遵循特定目录结构的文件集合。一个标准的 Chart 目录结构如下：
mychart/
├── Chart.yaml # Chart 元数据（名称、版本、描述等）
├── values.yaml # 默认配置值
├── values.schema.json # （可选）values 的 JSON Schema 校验
├── charts/ # （可选）子 Chart 依赖
│ └── subchart-1.0.0.tgz
├── templates/ # Kubernetes 资源模板（Go 模板语法）
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ ├── _helpers.tpl # （可选）模板辅助函数
│ └── NOTES.txt # （可选）安装后的提示信息
├── crds/ # （可选）CRD 定义（Helm 3 新增）
│ └── my-crd.yaml
└── README.md # （可选）使用说明| 文件/目录 | 作用 | 是否必需 |
|---|---|---|
Chart.yaml |
定义 Chart 名称、版本、API 版本、描述、关键字等元数据 | 是 |
values.yaml |
提供默认配置值，用户可通过 --set 或自定义 values 文件覆盖 |
是 |
templates/ |
存放 Go 模板文件，渲染后生成 Kubernetes 资源清单 | 是 |
charts/ |
存放子 Chart 依赖（.tgz 包），Helm 会自动解压处理 | 否 |
crds/ |
存放 CRD 定义文件，Helm 3 在安装时优先创建 CRD | 否 |
values.schema.json |
对 values.yaml 进行 JSON Schema 校验，确保用户输入合法 | 否 |
💡 最佳实践：在多集群环境中，建议将环境差异（如副本数、镜像标签、存储类）全部抽象到 values.yaml 中，通过不同 values 文件实现环境隔离，避免修改模板。
1.3 Tiller 到 Helm 3 的关键变化
从 Helm 2 升级到 Helm 3 不仅仅是移除 Tiller，还涉及多个核心机制的改变。下表总结了最重要的差异：
| 维度 | Helm 2（Tiller） | Helm 3（无 Tiller） |
|---|---|---|
| 架构 | 客户端 + 服务端 Tiller | 纯客户端，直接调用 Kubernetes API |
| Release 存储 | ConfigMaps（默认）或 Secrets | Secrets（默认），更安全 |
| 权限模型 | Tiller 拥有集群级权限，难以细粒度控制 | 使用 kubeconfig 中的 RBAC 权限，遵循最小权限原则 |
| 命名空间 | Release 作用域为集群，跨命名空间需额外配置 | Release 作用域为命名空间，天然隔离 |
| CRD 处理 | 需手动创建 CRD 或使用 helm install --set 钩子 |
支持 crds/ 目录，安装时自动创建 CRD |
| Chart 依赖 | 依赖管理通过 requirements.yaml |
依赖管理合并到 Chart.yaml 的 dependencies 字段 |
| 升级策略 | 三路策略（原配置 + 新配置 + 当前状态） | 三路策略（原配置 + 新配置 + 当前状态），但实现更健壮 |
| 安全风险 | Tiller 可能成为攻击目标，需额外加固 | 无 Tiller，攻击面减少 |
⚠ 迁移注意：从 Helm 2 迁移到 Helm 3 时，Release 存储从 ConfigMaps 变为 Secrets，需要使用 helm 2to3 插件进行数据迁移，否则历史 Release 将无法管理。
1.4 Helm 核心概念
理解以下五个核心概念是掌握 Helm 的基础，它们贯穿整个多集群配置与迁移流程：
- Chart：Helm 的打包格式，包含描述 Kubernetes 资源的一组模板和配置文件。Chart 可以被版本化、分发和复用。
- Release：Chart 在 Kubernetes 集群中的一次运行实例。每次
helm install都会创建一个新的 Release，helm upgrade会更新现有 Release。 - Repository：用于存储和分发 Chart 的 HTTP/HTTPS 服务器。多集群环境中，通常需要自建或使用云厂商的 Chart 仓库（如 Harbor、ChartMuseum）。
- Values：Chart 的配置参数，通过
values.yaml或--set传入。多集群场景下，不同集群使用不同的 values 文件实现差异化配置。 - Config：Helm 3 中，Release 的配置信息存储在 Kubernetes Secrets 中，包括 values、manifest 和元数据。
多集群视角：在多集群环境中，同一个 Chart 可以通过不同的 values 文件部署到多个集群，每个集群对应一个独立的 Release。Chart 仓库作为中央分发点，确保所有集群使用相同版本的 Chart，而 values 文件则管理环境差异。
1.5 本章小结
本章回顾了 Helm 的基础知识，重点包括：
- 架构演进：从 Helm 2 的 Tiller 架构到 Helm 3 的纯客户端架构，安全性和简洁性大幅提升。
- Chart 结构：标准目录包含
Chart.yaml、values.yaml、templates/等核心文件，crds/和values.schema.json是 Helm 3 新增特性。 - 关键变化：Release 存储从 ConfigMaps 变为 Secrets，权限模型从 Tiller 超级管理员变为 RBAC 细粒度控制，CRD 处理自动化。
- 核心概念：Chart、Release、Repository、Values 四者构成 Helm 的工作闭环，理解它们的关系是多集群配置的基础。