3. Helm 核心概念：Chart、Release、Repository、Chart 版本与 App 版本、Helm 的工作流程
在正式使用 Helm 之前，必须透彻理解其五大核心概念。这些概念构成了 Helm 的语义基础，也是后续所有操作和排错的根基。本章将逐一拆解 Chart、Release、Repository、版本体系以及 Helm 的完整工作流程。
3.1 五大核心概念速览
| 概念 | 定义 | 类比（操作系统） | 关键特征 |
|---|---|---|---|
| Chart | Kubernetes 资源的打包模板与配置集合 | 软件安装包（.deb / .rpm） | 可版本化、可依赖、可分发 |
| Release | Chart 在目标集群中的一次运行实例 | 运行中的进程 | 每个 Release 有唯一名称，可升级、回滚、删除 |
| Repository | Chart 包的存储与索引仓库 | APT / YUM 软件源 | HTTP(S) 服务器 + index.yaml 索引文件 |
| Chart 版本 | Chart 包自身的迭代版本号（chartVersion） | 软件包版本（如 2.1.0） | 遵循 SemVer 2，修改模板或默认值即应升级 |
| App 版本 | Chart 所部署的应用软件的版本号（appVersion） | 软件本体版本（如 7.4.5） | 仅用于信息展示，Helm 不校验其语义 |
区分要点：Chart 版本变化代表部署模板或配置的变更；App 版本变化代表被部署软件的上游版本升级。两者可以独立演进，但通常建议在 Chart 版本升级时同步更新 appVersion 以保持可追溯性。
3.2 Chart：Kubernetes 应用的打包标准
Chart 是 Helm 的核心制品，本质是一个遵循特定目录结构的文件集合。一个标准的 Chart 目录结构如下：
mychart/
├── Chart.yaml # Chart 元数据（名称、版本、appVersion、依赖等）
├── values.yaml # 默认配置值
├── values.schema.json # （可选）values 的 JSON Schema 校验文件
├── charts/ # （可选）子 Chart 依赖包（.tgz 或目录）
├── crds/ # （可选）CRD 定义文件，仅安装时创建
├── templates/ # Go 模板文件，渲染后生成 Kubernetes 资源清单
│ ├── NOTES.txt # （可选）安装后的使用提示文本
│ ├── _helpers.tpl # （可选）模板辅助函数
│ ├── deployment.yaml
│ ├── service.yaml
│ └── ...
└── README.md # （可选）使用说明
Chart.yaml 是 Chart 的身份证，必须包含以下核心字段：
apiVersion: v2 # Helm 3 必须使用 v2
name: mychart # Chart 名称
description: A Helm chart for Kubernetes
type: application # application 或 library
version: 0.1.0 # Chart 版本
appVersion: "1.16.0" # 关联的应用版本
3.3 Release：Chart 的运行实例
当 Helm 将 Chart 安装到 Kubernetes 集群时，会产生一个 Release。Release 是 Chart 模板与用户提供的 values 值结合后，在集群中创建的一组 Kubernetes 资源的逻辑集合。
- 唯一标识：每个 Release 由用户指定的名称（release name）唯一标识，在同一命名空间内不可重复。
- 状态管理：Helm 在集群的
default命名空间（或指定命名空间）中创建 Secret 来存储 Release 的元数据、values 和渲染后的 manifest，用于支持升级和回滚。 - 生命周期：一个 Release 可以经历 install → upgrade → rollback → uninstall 等阶段。
常见误区：同一个 Chart 可以安装多次，每次生成一个独立的 Release。例如，使用同一个 Nginx Chart 安装
web-prod 和 web-staging 两个 Release，它们互不干扰。
3.4 Repository：Chart 的分发中心
Repository 是 Helm 的 Chart 分发机制。一个 Repository 本质上是一个能够提供 index.yaml 文件和 Chart 包（.tgz）下载的 HTTP(S) 服务器。
- index.yaml：仓库的索引文件，包含所有 Chart 的名称、版本、描述、下载 URL 和校验值。
- 操作命令：
helm repo add添加仓库，helm repo update更新本地缓存，helm search repo搜索 Chart。 - 官方仓库：Bitnami 仓库（
https://charts.bitnami.com/bitnami）是目前最活跃的公共仓库。
3.5 版本体系：Chart 版本与 App 版本
Helm 在 Chart.yaml 中维护了两个独立的版本号，理解它们的区别至关重要。
| 属性 | 字段名 | 语义 | 变更时机 | Helm 行为 |
|---|---|---|---|---|
| Chart 版本 | version |
Chart 包自身的版本 | 模板、默认值、依赖关系发生变化时 | 用于仓库索引和依赖解析，必须递增 |
| App 版本 | appVersion |
Chart 所部署的应用软件版本 | 上游应用发布新版本时 | 仅作为信息展示，不影响依赖解析 |
# Chart.yaml 示例
version: 1.2.0 # Chart 版本：修改了模板中的环境变量配置
appVersion: "3.4.1" # App 版本：应用从 3.4.0 升级到 3.4.1
最佳实践：每次修改 Chart 模板或 values 默认值后，务必递增
version 字段。仅当上游应用版本变更时，才更新 appVersion。两者使用不同的版本号可以清晰区分“部署方式变更”和“应用版本变更”。
3.6 Helm 的工作流程
Helm 的核心工作流程分为三个阶段：模板渲染、资源安装/升级、Release 记录。下图展示了从 Chart 到 Release 的完整路径。
工作流程的详细步骤说明：
- 加载 Chart：Helm 从本地目录或 Repository 中加载 Chart 包，解析
Chart.yaml和依赖关系。 - 合并 Values：将用户提供的 values（
-f文件或--set参数）与 Chart 中的values.yaml进行深度合并，用户值优先级最高。 - 模板渲染：渲染引擎将合并后的 values 注入到
templates/目录下的 Go 模板文件中，执行条件判断、循环、变量替换等逻辑，生成完整的 Kubernetes YAML 清单。 - 校验与预处理：Helm 对渲染结果进行基本的格式校验，并处理 Helm Hook（如预安装、预删除等钩子）。
- 调用 Kubernetes API：将最终的 YAML 清单通过 Kubernetes API 发送到集群，创建或更新资源。
- 记录 Release：在集群中创建或更新一个 Secret，保存 Release 的名称、Chart 版本、用户 values、渲染后的 manifest 以及当前状态（deployed、failed、superseded 等）。
- 输出结果：返回安装/升级结果，并显示
NOTES.txt中的使用提示。
3.7 核心概念关系图
为了更直观地理解 Chart、Repository、Release 三者之间的关系，下图展示了从仓库到集群实例的完整链路。
核心关系总结：
- Repository 是 Chart 的存储和分发源，一个 Repository 可以包含多个 Chart 的多个版本。
- Chart 是模板和配置的打包单元，可以从 Repository 下载或本地创建。
- Release 是 Chart 在集群中的运行实例，同一个 Chart 可以创建多个 Release（如 prod、staging、dev），每个 Release 拥有独立的配置和生命周期。
3.8 本章小结
- Chart 是 Helm 的打包格式，包含模板、默认值和元数据。
- Release 是 Chart 的一次部署实例，具有唯一名称和独立状态。
- Repository 是 Chart 的远程存储和索引服务。
- Chart 版本 标识模板和配置的变更；App 版本 标识被部署应用的版本。
- Helm 工作流程：加载 Chart → 合并 Values → 模板渲染 → 调用 Kubernetes API → 记录 Release。