3. Helm 核心概念：Chart、Release、Repository、Values、Templates 的深度解析

Helm 作为 Kubernetes 的包管理工具，其核心概念构成了整个编排体系的基石。理解 Chart、Release、Repository、Values 和 Templates 这五个要素，是掌握 Helm 治理集群生命周期的第一步。本节将从定义、关系、使用场景三个维度进行深度拆解。

3.1 五大核心概念总览

下表从定义、功能、类比三个角度快速建立对五个核心概念的初步认知：

3.2 Chart：应用的定义包

Chart 是 Helm 的核心交付物。一个标准的 Chart 目录结构如下：

mychart/
├── Chart.yaml          # Chart 元数据（名称、版本、描述）
├── values.yaml         # 默认配置值
├── charts/             # 子 Chart 依赖（手动或通过 helm dependency 管理）
├── templates/          # Go 模板文件目录
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── _helpers.tpl    # 模板辅助函数
│   └── NOTES.txt       # 安装后的提示信息
└── .helmignore         # 打包时忽略的文件模式

3.3 Release：运行中的实例

当执行 helm install 时，Helm 会将 Chart 渲染并部署到集群，生成一个 Release。Release 是 Helm 管理应用生命周期的基本单元。

• 唯一标识：每个 Release 在命名空间内拥有唯一的名称。
• 版本控制：每次 helm upgrade 都会创建一个新的 Release 版本（Revision）。
• 回滚能力：通过 helm rollback 可以快速恢复到之前的 Revision。
• 数据存储：Release 的元数据和历史版本信息默认存储在集群的 Secret 中（位于目标命名空间）。

# 查看命名空间下的所有 Release
helm list -n production

# 查看某个 Release 的历史版本
helm history my-release -n production

# 回滚到 Revision 2
helm rollback my-release 2 -n production

3.4 Repository：Chart 的分发中心

Repository 是一个简单的 HTTP 服务器，托管 index.yaml 索引文件和 Chart 压缩包（.tgz）。Helm 客户端通过仓库索引来搜索和拉取 Chart。

# 添加仓库
helm repo add bitnami https://charts.bitnami.com/bitnami

# 更新仓库索引
helm repo update

# 搜索仓库中的 Chart
helm search repo bitnami/nginx

# 移除仓库
helm repo remove bitnami

下图展示了 Helm 客户端、Repository 与 Kubernetes 集群之间的交互流程：

3.5 Values：配置与模板的解耦

Values 是 Helm 实现环境差异化配置的关键。通过将可变参数从模板中抽离，同一个 Chart 可以部署到开发、测试、生产等多个环境，只需提供不同的 Values 文件。

Values 的优先级（从低到高）：

1. values.yaml：Chart 内嵌的默认值。
2. 父 Chart 的 values.yaml：当存在子 Chart 依赖时。
3. helm install -f myvalues.yaml：用户指定的外部 YAML 文件。
4. helm install --set key=value：命令行直接传入的参数（优先级最高）。

3.6 Templates：动态资源生成引擎

Templates 目录下的文件使用 Go 模板语法，结合 Values 和内置对象，动态生成最终的 Kubernetes 资源清单。

核心模板语法示例：

{{- /* deployment.yaml 片段 */ -}}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
  labels:
    app.kubernetes.io/name: {{ .Chart.Name }}
    app.kubernetes.io/instance: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .Chart.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}

内置对象说明：

3.7 核心概念关系图

下图展示了 Chart、Values、Templates 如何协作生成最终的 Kubernetes 资源，并形成 Release：

3.8 核心概念在配置漂移审计中的角色

在《Helm 治理 K8s 平台集群生命周期运维配置漂移审计》课程中，这五个概念各自承担着关键的审计角色：

• Chart（版本化基线）：Chart 的版本号直接对应应用定义的基线。审计时通过对比不同版本的 Chart，可以快速识别资源定义的变更。
• Release（实例快照）：Release 的 Revision 历史记录了每一次部署操作。审计人员可以遍历所有 Revision，查看任意时间点的集群状态。
• Repository（供应链安全）：通过审计 Repository 的访问日志和 Chart 的签名（Provenance），可以确保部署的 Chart 来自可信源，防止供应链攻击。
• Values（配置差异）：Values 文件是配置漂移的主要来源。审计时通过 helm diff 或 Git 对比，可以精确发现不同环境或不同 Revision 之间的配置差异。
• Templates（渲染结果）：审计最终的渲染输出（helm get manifest）是确认实际下发到集群的资源是否符合预期的最终手段。

# 查看当前 Release 的 Values
helm get values my-release -n production

# 查看当前 Release 的 Manifest（渲染后的 YAML）
helm get manifest my-release -n production

# 对比当前 Release 与 Revision 1 的差异
helm diff revision my-release 1 -n production