3. Helm 基础:Chart结构、模板引擎、Values文件、Release管理
Helm 是 Kubernetes 生态中最流行的包管理工具,它将复杂的应用资源定义封装为 Chart,并通过模板引擎实现参数化部署。理解 Chart 结构、模板引擎、Values 文件以及 Release 管理,是掌握 Helm 故障域隔离演练的前提。
3.1 Chart 目录结构
一个标准的 Helm Chart 遵循固定的目录布局,每个文件和文件夹都有明确的职责:
| 路径 / 文件 | 必需 | 说明 |
|---|---|---|
Chart.yaml |
是 | Chart 的元数据文件,包含名称、版本、描述、API 版本等 |
values.yaml |
是 | 默认的配置值文件,定义所有可配置参数的默认值 |
templates/ |
是 | 存放 Go 模板文件,渲染后生成 Kubernetes 资源清单 |
charts/ |
否 | 存放子 Chart 依赖(Subchart)的目录 |
crds/ |
否 | 存放自定义资源定义(CRD)的 YAML 文件 |
templates/NOTES.txt |
否 | 安装成功后向用户显示的帮助信息模板 |
templates/_helpers.tpl |
否 | 存放可复用的模板命名片段(Named Templates) |
💡 最佳实践: 在故障域隔离场景中,建议将不同可用区的配置差异抽象为 Values 中的嵌套字段,而非创建多个 Chart 副本。
3.2 模板引擎与 Values 文件
Helm 使用 Go 模板引擎将 values.yaml 中的值注入到 templates/ 目录下的资源文件中。模板语法以 {{ }} 为标记,支持变量、管道、控制结构和命名模板。
核心模板语法
# 引用顶层值
replicas: {{ .Values.replicaCount }}
# 引用嵌套值
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
# 条件判断
{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
{{- end }}
# 遍历列表
{{- range .Values.ports }}
- containerPort: {{ . }}
{{- end }}
# 使用命名模板(在 _helpers.tpl 中定义)
{{ include "myapp.labels" . }}
Values 文件层级与作用域
Values 文件支持多层级覆盖,优先级从低到高依次为:
- Chart 内置
values.yaml—— 默认值 - 父 Chart 的 Values —— 当 Chart 作为子 Chart 时继承
- 用户自定义
-f myvalues.yaml—— 覆盖默认值 - 命令行
--set key=value—— 最高优先级
⚠️ 故障域隔离注意: 使用
--set 覆盖大量参数容易导致配置漂移。建议为每个故障域(如可用区 A/B)准备独立的 Values 文件,通过 -f 参数加载,确保可审计和可重复。
3.3 Release 管理
Release 是 Helm 在 Kubernetes 集群中安装 Chart 后生成的 运行实例。每次安装、升级、回滚或删除操作都会在集群中留下记录,Helm 通过 Release 名称和版本号追踪这些变更。
核心 Release 操作
| 命令 | 功能 | 故障域场景示例 |
|---|---|---|
helm install |
安装一个新的 Release | helm install web-az-a ./webapp -f values-az-a.yaml |
helm upgrade |
升级一个已有的 Release | helm upgrade web-az-a ./webapp -f values-az-a.yaml --set image.tag=v2 |
helm rollback |
回滚到指定版本 | helm rollback web-az-a 1(回滚到第 1 个版本) |
helm uninstall |
删除 Release 及其资源 | helm uninstall web-az-a |
helm list |
列出所有 Release | helm list -n production |
helm history |
查看 Release 的版本历史 | helm history web-az-a |
🔑 关键概念: Release 名称在命名空间内必须唯一。在故障域隔离演练中,建议采用
<应用名>-<故障域标识> 的命名规范,例如 webapp-az-a、webapp-az-b,便于管理和监控。
3.4 内置对象与作用域
Helm 模板引擎提供了多个内置对象,用于在模板中访问上下文信息:
| 内置对象 | 说明 | 故障域场景用途 |
|---|---|---|
.Values |
访问 Values 文件中的配置值 | 读取故障域专属参数(如可用区标签、节点亲和性) |
.Release |
访问 Release 元数据(Name、Namespace、Revision 等) | 通过 .Release.Name 区分不同故障域的实例 |
.Chart |
访问 Chart.yaml 中的元数据 | 在资源标签中注入 Chart 版本,便于追踪 |
.Files |
访问 Chart 包内的非模板文件 | 加载故障域专用的配置文件(如 Prometheus 规则) |
.Capabilities |
访问 Kubernetes 集群的能力信息 | 根据集群版本条件启用/禁用特定 API 资源 |
# 故障域场景模板示例:利用 Release 名称和 Values 生成差异化资源
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name }}-web
labels:
app: webapp
zone: {{ .Values.zone }}
release: {{ .Release.Name }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: webapp
zone: {{ .Values.zone }}
template:
metadata:
labels:
app: webapp
zone: {{ .Values.zone }}
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- {{ .Values.zone }}
containers:
- name: web
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
env:
- name: ZONE
value: {{ .Values.zone }}
📐 设计原则: 在故障域隔离演练中,模板应保持 无状态 —— 所有差异化配置通过 Values 注入,模板本身不包含硬编码的可用区逻辑。这样,新增一个故障域只需添加一个 Values 文件,无需修改 Chart 模板。