2. Helm基础回顾
在深入多集群配置之前，必须重新夯实 Helm 的核心基础。本章将系统回顾 Helm 从 Tiller 时代到 Helm 3 无服务器架构的演进、Chart 的标准目录结构、Release 的生命周期管理以及 Repository 的常用操作。这些知识是后续理解控制平面与 Values 管理的前提。
2.1 Helm 架构演进：Tiller vs Helm 3
Helm 的架构经历了从客户端-服务端（C/S）到纯客户端（Client-Only）的重大变革。理解这一演进有助于你选择正确的部署策略并规避安全风险。
| 对比维度 | Helm 2 (Tiller 架构) | Helm 3 (无 Tiller 架构) |
|---|---|---|
| 核心组件 | Helm CLI（客户端）+ Tiller（服务端） | Helm CLI（客户端） |
| 部署位置 | Tiller 部署在集群内的 kube-system 命名空间 |
无服务端组件，CLI 直接通过 kubeconfig 与 API Server 交互 |
| 权限模型 | Tiller 拥有集群级权限，存在安全风险 | 使用当前用户的 kubeconfig 权限，遵循 RBAC |
| Release 存储 | ConfigMap 或 Secrets（默认 ConfigMap） | Secrets（默认），每个 Release 对应一个 Secret |
| Chart 安装 | Tiller 在服务端渲染模板并安装 | Helm CLI 在客户端渲染模板，通过 API 安装 |
| 升级策略 | 两阶段升级（Tiller 协调） | 三路策略合并（当前配置、上次配置、新配置） |
关键结论：Helm 3 移除了 Tiller，消除了服务端权限泄露的风险，同时引入了更可靠的三路合并升级策略。所有生产环境应使用 Helm 3。
2.2 Chart 结构：标准目录与核心文件
一个 Helm Chart 是一个遵循特定目录结构的软件包。理解其内部结构是编写和定制 Chart 的基础。
my-chart/
├── Chart.yaml # Chart 元数据（名称、版本、描述等）
├── values.yaml # 默认配置值
├── values.schema.json # （可选）values 的 JSON Schema 校验文件
├── charts/ # （可选）子 Chart 依赖
│ └── sub-chart-1.0.0.tgz
├── templates/ # 模板文件目录（核心）
│ ├── NOTES.txt # （可选）安装后的使用说明
│ ├── _helpers.tpl # （可选）模板辅助函数
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── ingress.yaml
│ └── hpa.yaml
└── crds/ # （可选）CRD 定义目录（Helm 3.2+）
└── my-crd.yaml| 文件/目录 | 作用 | 是否必须 |
|---|---|---|
Chart.yaml |
定义 Chart 名称、版本、API 版本、描述、关键字等 | 是 |
values.yaml |
提供默认配置值，供模板引用 | 是 |
templates/ |
存放 Go 模板文件，最终渲染为 Kubernetes 资源清单 | 是 |
charts/ |
存放子 Chart 的打包文件（.tgz），用于管理依赖 | 否 |
crds/ |
存放 CRD 定义，Helm 会在安装时先安装 CRD | 否 |
values.schema.json |
对 values.yaml 进行结构校验，防止错误配置 | 否 |
最佳实践：始终为生产级 Chart 提供
values.schema.json 文件。它可以在安装或升级时提前捕获类型错误、缺失字段等问题，避免将错误配置推送到集群。
2.3 Release 管理：生命周期与常用命令
Release 是 Chart 的一次具体部署实例。每次 helm install 或 helm upgrade 都会创建一个新的 Release 版本。Helm 3 使用 Secrets 存储 Release 历史，支持回滚和审计。
常用 Release 管理命令
# 安装一个 Chart，创建 Release
helm install my-release ./my-chart --namespace production
# 升级 Release，支持 --values 覆盖配置
helm upgrade my-release ./my-chart --values prod-values.yaml
# 查看 Release 历史
helm history my-release -n production
# 回滚到指定版本
helm rollback my-release 2 -n production
# 卸载 Release
helm uninstall my-release -n production
注意：Helm 3 默认保留 Release 历史记录。如果频繁升级，历史记录会占用 Secrets 资源。可以使用
--history-max 参数限制保留的版本数量。
2.4 Repository 操作：Chart 的远程仓库管理
Repository（仓库）是存储和分发 Chart 包的远程服务器。Helm 支持多种仓库类型，包括 OCI 和传统 Chart 仓库。
| 操作 | 命令示例 | 说明 |
|---|---|---|
| 添加仓库 | helm repo add bitnami https://charts.bitnami.com/bitnami |
将远程仓库添加到本地索引 |
| 更新仓库 | helm repo update |
拉取最新仓库索引，获取最新 Chart 列表 |
| 搜索 Chart | helm search repo bitnami/nginx |
在已添加的仓库中搜索 Chart |
| 查看仓库列表 | helm repo list |
列出所有已配置的仓库 |
| 移除仓库 | helm repo remove bitnami |
从本地索引中移除仓库 |
| OCI 登录 | helm registry login registry.example.com |
登录 OCI 兼容的容器镜像仓库 |
OCI 仓库与传统仓库对比
| 特性 | 传统 Chart 仓库 | OCI 仓库 |
|---|---|---|
| 存储格式 | 索引文件（index.yaml）+ tgz 包 | OCI 镜像层（manifest + layers） |
| 认证方式 | 基本认证或 | Docker Registry 认证（Bearer ） |
| 版本管理 | 基于 index.yaml 的版本列表 | 基于 OCI 标签（tag） |
| 多架构支持 | 不原生支持 | 原生支持多架构镜像 |
| Helm 版本 | Helm 2 / 3 | Helm 3.8+（实验性功能，3.12+ 稳定） |
推荐：对于新项目，建议使用 OCI 仓库。它利用现有的容器镜像基础设施（如 Harbor、AWS ECR、Azure ACR），提供统一的认证和审计能力，更适合企业级多集群场景。
OCI 仓库操作示例
# 登录 OCI 仓库
helm registry login registry.example.com --username admin --password-stdin
# 推送 Chart 到 OCI 仓库
helm push ./my-chart-1.0.0.tgz oci://registry.example.com/helm-charts
# 从 OCI 仓库安装 Chart
helm install my-release oci://registry.example.com/helm-charts/my-chart --version 1.0.0
# 从 OCI 仓库拉取 Chart 到本地
helm pull oci://registry.example.com/helm-charts/my-chart --version 1.0.0