📚 课程目录第3章 Helm基础回顾

3. Helm 基础回顾：Helm 架构、Chart 结构、Values 文件、模板引擎、Release 管理

在深入 Kong 网关的资源配额模型之前，必须牢固掌握 Helm 的核心机制。Helm 是 Kubernetes 生态中最流行的包管理工具，它将复杂的应用定义抽象为可配置、可版本化的 Chart。本节将系统回顾 Helm 的五大核心概念：架构、Chart 结构、Values 文件、模板引擎以及 Release 管理，为后续的 Kong Helm Chart 定制打下坚实基础。

3.1 Helm 架构与核心组件

Helm 采用客户端-服务器架构，主要由以下两个组件构成：

Helm CLI（客户端）：负责本地 Chart 开发、仓库管理、以及将 Chart 发布到 Kubernetes 集群。它通过 gRPC 与 Tiller（v2）或直接通过 Kubernetes API Server（v3）交互。
Tiller（Helm v2）/ 无服务器端（Helm v3）：Helm v2 在集群内运行 Tiller 服务端，拥有较高权限；Helm v3 移除了 Tiller，直接在客户端通过 Kubernetes 的 kubeconfig 文件与 API Server 通信，安全性更高，架构更简洁。

版本选择建议： 当前主流环境已全面采用 Helm v3。本课程所有示例均基于 Helm v3 语法，不再兼容 Tiller 模式。

3.2 Chart 目录结构

一个标准的 Helm Chart 是一个遵循特定目录结构的文件集合。以 Kong 官方 Chart 为例，其核心结构如下：

文件/目录	是否必须	说明
`Chart.yaml`	是	Chart 的元数据文件，包含名称、版本、描述、API 版本等。
`values.yaml`	是	默认配置值文件，用户通过覆盖此文件实现自定义部署。
`templates/`	是	存放 Go 模板文件，渲染后生成 Kubernetes 资源清单（YAML）。
`charts/`	否	存放子 Chart 依赖，例如 Kong 网关可能依赖 `postgresql` 或 `ingress-nginx`。
`crds/`	否	存放自定义资源定义（CRD），Helm v3 会在安装时自动应用这些 CRD。
`templates/NOTES.txt`	否	安装成功后向用户显示的帮助信息，例如访问地址、默认密码等。

  关键点： templates/ 目录下的文件名没有强制要求，但通常按资源类型命名，如 deployment.yaml、service.yaml、hpa.yaml。Kong 的 Chart 中还会包含 kong-config.yaml 用于管理网关配置。

3.3 Values 文件与值传递

Values 文件是 Helm 灵活性的核心。它允许将配置与模板分离，实现环境差异化部署。

默认值文件（values.yaml）：Chart 自带的默认配置，定义了所有可配置参数的初始值。
用户自定义值文件：通过 -f 或 --values 参数指定，会合并并覆盖默认值。
命令行设置：通过 --set 参数直接设置单个值，优先级最高。

值合并遵循以下优先级（从低到高）：

values.yaml（Chart 内置）
父 Chart 的 values.yaml（如果存在依赖关系）
通过 -f 指定的用户值文件（多个文件按顺序合并，后覆盖前）
通过 --set 指定的参数

注意： 在 Helm v3 中，--set 参数对复杂数据结构（如列表、嵌套对象）的支持有限。对于 Kong 的资源配额配置，建议始终使用 -f 指定完整的 YAML 文件，避免 --set 导致的类型转换错误。

3.4 模板引擎与内置对象

Helm 使用 Go 的 text/template 引擎，并扩展了 50 多个模板函数（来自 Sprig 库）。模板文件通过 {{ }} 语法引用 Values 和内置对象。

以下是模板文件中常用的内置对象：

对象	描述	示例
`.Values`	访问用户提供的配置值	`{{ .Values.replicaCount }}`
`.Release`	Release 元数据（Name、Namespace、Service、Revision）	`{{ .Release.Name }}`
`.Chart`	Chart.yaml 中的元数据	`{{ .Chart.Version }}`
`.Files`	访问 Chart 中的非模板文件	`{{ .Files.Get "config/kong.conf" }}`
`.Capabilities`	Kubernetes 集群能力信息（API 版本、特性门控）	`{{ .Capabilities.APIVersions.Has "apps/v1" }}`

一个典型的模板片段（用于生成 Kong Deployment 的资源请求）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-kong
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: kong
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            requests:
              cpu: {{ .Values.resources.requests.cpu }}
              memory: {{ .Values.resources.requests.memory }}
            limits:
              cpu: {{ .Values.resources.limits.cpu }}
              memory: {{ .Values.resources.limits.memory }}

3.5 Release 生命周期管理

Release 是 Helm 的核心抽象，代表 Chart 的一次部署实例。每次安装、升级、回滚都会产生一个新的 Release 版本（Revision）。

常用的 Release 管理命令：

命令	功能	常用参数
`helm install`	安装一个新的 Release	`--name` (v2), `--namespace`, `-f`
`helm upgrade`	升级一个已存在的 Release	`--install` (不存在则安装), `--reset-values`
`helm rollback`	回滚到指定的 Release 版本	`--recreate-pods`
`helm list`	列出所有已部署的 Release	`--all-namespaces`, `--deployed`
`helm uninstall`	卸载一个 Release	`--keep-history` (保留历史记录)

生产实践： 在升级 Kong 网关时，建议先使用 helm upgrade --dry-run --debug 进行预演，检查模板渲染结果是否符合预期，避免因 Values 错误导致网关中断。