2. Helm 基础回顾：Chart 结构、模板引擎、Values 文件的作用与优先级、Release 管理

在深入网络拓扑与数据传输效率优化之前，必须重新夯实 Helm 的核心基础。本章将系统梳理 Chart 的物理结构、模板引擎的工作机制、Values 文件的层级优先级以及 Release 的生命周期管理，为后续的 Values 策略设计提供坚实的理论支撑。

2.1 Chart 目录结构与核心文件

一个标准的 Helm Chart 遵循固定的目录布局，每个文件和目录都有明确的职责。理解这一结构是编写可维护 Chart 的前提。

路径 / 文件 是否必需 作用说明
Chart.yaml 是 Chart 的元数据文件，包含名称、版本、API 版本、描述等。
values.yaml 是 默认的 Values 配置文件，定义所有可配置参数的默认值。
templates/ 是 存放 Go 模板文件，渲染后生成 Kubernetes 资源清单。
charts/ 否 存放子 Chart（依赖 Chart）的打包文件或目录。
crds/ 否 存放自定义资源定义（CRD），Helm 会优先安装此目录下的 CRD。
templates/NOTES.txt 否 安装成功后向用户显示的帮助信息模板。
templates/_helpers.tpl 否 存放可复用的模板命名片段（named templates），通过 include 调用。
最佳实践： 在 templates/ 目录下，建议按资源类型组织文件，例如 deployment.yaml、service.yaml、configmap.yaml，避免将所有资源写入单个巨型模板文件。
Helm Chart 标准目录结构 my-chart/ Chart.yaml values.yaml templates/ charts/ crds/ deployment.yaml service.yaml _helpers.tpl NOTES.txt

2.2 模板引擎核心机制

Helm 使用 Go 的 text/template 引擎，结合 Sprig 函数库，将静态模板与动态 Values 数据融合，生成最终的 Kubernetes YAML 清单。

2.2.1 模板语法三要素

  • 指令标记： {{ ... }} 用于执行模板指令，包括取值、控制流、函数调用。
  • 取值操作： .Values 引用 Values 文件中的数据；.Release 引用 Release 元数据；.Chart 引用 Chart.yaml 中的字段。
  • 管道与函数： | 将前一个输出传递给后一个函数，例如 {{ .Values.name | default "nginx" | quote }}。
关键内置对象：
  • .Values — 合并后的 Values 配置
  • .Release.Name — Release 名称
  • .Release.Namespace — 目标命名空间
  • .Chart.Name — Chart 名称
  • .Files — 访问 Chart 内非模板文件

2.2.2 控制流与变量

{{- /* 条件判断 */ -}}
{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
spec:
  type: {{ .Values.service.type }}
{{- else }}
# Service 未启用
{{- end }}

{{- /* 循环遍历 */ -}}
{{- range .Values.ports }}
  - port: {{ .port }}
    targetPort: {{ .targetPort }}
{{- end }}

{{- /* 定义并使用局部变量 */ -}}
{{- $fullName := printf "%s-%s" .Release.Name .Chart.Name }}
注意： 模板中的 -（如 {{- 或 -}}）用于修剪空白字符，避免生成的 YAML 出现多余空行。在生成网络策略或 Service 拓扑时，空白控制直接影响 YAML 的解析正确性。

2.3 Values 文件的作用与优先级

Values 是 Helm 的配置核心，它允许将环境差异、部署参数与模板逻辑解耦。理解 Values 的合并优先级是避免配置覆盖混乱的关键。

2.3.1 优先级层级（从低到高）

优先级 来源 说明
1（最低） values.yaml（Chart 内置） Chart 开发者提供的默认值，作为基线配置。
2 子 Chart 的 values.yaml 依赖 Chart 的默认值，通过 parent.child.key 路径访问。
3 -f values-production.yaml 用户通过 --values 或 -f 指定的外部 YAML 文件。
4 --set key=value 命令行直接设置的键值对，支持逗号分隔和 JSON 路径。
5（最高） --set-string / --set-json 强制以字符串或 JSON 格式覆盖，避免类型推断错误。
网络拓扑场景提示： 当管理多集群网络拓扑时，建议将集群通用的网络基线写入 values.yaml，将特定集群的 CIDR、节点端口范围、负载均衡器 IP 通过 -f 文件注入，避免在 --set 中编写过长参数。
Values 优先级合并流程（从低到高） 1. Chart 内置 values.yaml（基线默认值） 2. 子 Chart values.yaml（依赖覆盖） 3. -f 外部文件（环境差异化配置） 4. --set 命令行键值对（临时覆盖） 5. --set-string / --set-json（最高优先级强制覆盖）

2.4 Release 管理

Release 是 Helm 部署 Chart 后产生的运行实例。每个 Release 都有唯一的名称、版本号和状态，Helm 通过 Release 记录实现安装、升级、回滚和卸载。

2.4.1 Release 生命周期命令

命令 作用 网络拓扑场景示例
helm install 创建新的 Release helm install net-topology ./network-chart -f prod-values.yaml
helm upgrade 升级现有 Release，支持 Values 增量更新 helm upgrade net-topology ./network-chart --set network.cidr=10.0.0.0/16
helm rollback 回滚到指定历史版本 helm rollback net-topology 2（回滚到第 2 次部署）
helm uninstall 删除 Release 并清理资源 helm uninstall net-topology
helm list 列出当前命名空间下的所有 Release helm list -n network-system
helm history 查看 Release 的部署历史 helm history net-topology

2.4.2 升级策略与 Values 持久化

Helm 默认使用 滚动升级 策略，但可以通过 Values 控制 strategy 字段。在升级时，Helm 会将当前使用的 Values 快照保存到 Release 记录中，确保回滚时能恢复完全一致的配置。

关键参数：
  • --reuse-values：复用上一次 Release 的 Values，忽略当前 Values 变更（谨慎使用，容易导致配置漂移）。
  • --reset-values：重置 Values 为 Chart 默认值，再应用本次指定的覆盖。
  • --history-max：设置保留的最大历史版本数，默认 10，建议生产环境设置为 5 以节省 etcd 存储。
网络拓扑变更风险： 修改网络策略、Service CIDR 或 LoadBalancer IP 时，务必先执行 helm diff upgrade（需安装 helm-diff 插件）预览变更内容，避免升级导致网络中断。

2.5 本章小结

← 上一章 📖 返回目录 下一章 →