2. Helm 基础回顾：Helm 架构、Chart 结构、Release 概念
在深入镜像拉取加速方案之前，有必要重新梳理 Helm 的核心基础。Helm 是 Kubernetes 生态中的包管理工具，它将复杂的应用部署抽象为三个核心概念：Chart（包）、Release（实例）和 Repository（仓库）。理解这三者的关系以及 Helm 的架构设计，是后续配置加速环境的前提。
2.1 Helm 整体架构
Helm 采用客户端-服务器（C/S）架构。客户端是 Helm CLI，负责本地 Chart 开发、打包和仓库管理；服务器端是 Tiller（Helm 2）或直接通过 Helm SDK 与 Kubernetes API Server 交互（Helm 3）。Helm 3 移除了 Tiller，安全性更高，也是当前主流版本。
架构演进要点： Helm 3 不再依赖集群内的 Tiller 组件，Release 信息直接存储在 Kubernetes 的 Secret 资源中，避免了 RBAC 权限扩散问题。
2.2 Chart 结构详解
一个 Helm Chart 是描述一组 Kubernetes 资源的文件集合。标准的 Chart 目录结构如下：
my-chart/
├── Chart.yaml # Chart 元数据（名称、版本、描述等）
├── values.yaml # 默认配置值
├── values.schema.json # （可选）values 的 JSON Schema 校验
├── charts/ # 子 Chart 依赖（.tgz 包或目录）
├── templates/ # Go 模板文件，生成 K8s 资源清单
│ ├── deployment.yaml
│ ├── service.yaml
│ ├── _helpers.tpl # 模板辅助函数
│ └── NOTES.txt # 安装后的提示信息
└── README.md # 使用说明| 文件/目录 | 作用 | 是否必须 |
|---|---|---|
Chart.yaml |
定义 Chart 名称、API 版本、应用版本、依赖等 | 是 |
values.yaml |
提供默认配置值，用户可通过 --set 或自定义文件覆盖 |
是 |
templates/ |
存放 Go template 文件，渲染后生成最终的 YAML 清单 | 是 |
charts/ |
存放子 Chart 依赖包，用于复杂应用的模块化 | 否 |
values.schema.json |
对 values.yaml 进行结构化校验，防止错误配置 | 否 |
实践建议： 在镜像拉取加速场景中，
values.yaml 是配置镜像仓库地址、拉取策略和认证信息的关键入口。合理利用 values.schema.json 可以提前拦截无效的镜像地址格式。
2.3 Release 概念与生命周期
Release 是 Chart 在 Kubernetes 集群中的一次运行实例。每次执行 helm install 都会创建一个新的 Release；每次 helm upgrade 则会生成一个新的 Release 版本。Helm 3 将 Release 信息存储在目标命名空间的 Secret 中，命名格式为 sh.helm.release.v1.<release-name>.v<version>。
2.4 核心命令速查
以下命令在镜像拉取加速的部署流程中会频繁使用：
| 命令 | 用途 | 加速场景关联 |
|---|---|---|
helm repo add |
添加 Chart 仓库 | 配置私有镜像仓库对应的 Chart 源 |
helm pull |
下载 Chart 包到本地 | 可结合代理或镜像站加速 Chart 下载 |
helm install |
安装 Chart 生成 Release | 通过 --set 注入加速后的镜像地址 |
helm upgrade |
升级 Release 到新版本 | 更新镜像拉取配置，实现滚动更新 |
helm list |
列出所有 Release | 确认加速配置是否生效 |
helm get values |
查看 Release 的当前配置 | 调试镜像地址是否正确覆盖 |
常见误区： 初学者容易混淆
Chart 版本 和 Release 版本。Chart 版本在 Chart.yaml 中定义，用于标识 Chart 包本身的迭代；Release 版本是 Helm 自动递增的部署序号，用于追踪每次 helm upgrade 的变更历史。在镜像加速场景中，修改 values.yaml 中的镜像标签后执行 helm upgrade，Release 版本会增加，但 Chart 版本通常保持不变。