2. Helm 基础回顾:Chart 结构、模板引擎、Values 管理、Release 生命周期
在深入故障域隔离与容量突增演练之前,必须夯实 Helm 的核心基础。Helm 是 Kubernetes 的包管理工具,它将应用定义、配置与部署逻辑封装为 Chart,并通过模板引擎实现环境差异化。本节将系统回顾 Chart 结构、模板引擎机制、Values 分层管理以及 Release 的完整生命周期。
2.1 Chart 目录结构
一个标准的 Helm Chart 遵循固定的目录布局,每个文件和目录都有明确的职责。下表列出了核心组件及其用途:
| 路径 / 文件 | 必需 | 说明 |
|---|---|---|
Chart.yaml |
是 | Chart 元数据:名称、版本、API 版本、描述、依赖声明等 |
values.yaml |
是 | 默认配置值,供模板引用;用户可通过 --set 或自定义 values 文件覆盖 |
templates/ |
是 | 存放 Go 模板文件(.yaml、.tpl),渲染后生成 Kubernetes 资源清单 |
charts/ |
否 | 子 Chart 依赖(手动或通过 helm dependency update 填充) |
crds/ |
否 | 自定义资源定义(CRD),在模板渲染前安装 |
templates/NOTES.txt |
否 | 安装成功后输出的使用说明文本 |
templates/_helpers.tpl |
否 | 存放可复用的模板子函数(named templates) |
SRE 视角: 在故障域隔离演练中,
values.yaml 通常按环境(dev/staging/prod)和故障域(az1/az2/region-b)拆分,避免硬编码。CRD 目录用于管理 Prometheus Operator 等依赖的 CRD 版本。
2.2 模板引擎与数据注入
Helm 使用 Go 模板引擎将 values.yaml 中的值注入到 Kubernetes 资源文件中。核心语法包括:
- 对象访问:
{{ .Values.replicaCount }}—— 从根对象.开始取值。 - 管道与函数:
{{ .Values.image.tag | default "latest" | quote }}—— 设置默认值并加引号。 - 控制结构:
{{- if .Values.service.enabled }} ... {{- end }}—— 条件渲染资源。 - 范围迭代:
{{- range .Values.ingress.hosts }} ... {{- end }}—— 遍历列表生成多个条目。 - 命名模板:在
_helpers.tpl中定义{{- define "myapp.labels" -}},在模板中通过{{ include "myapp.labels" . }}复用。
# 示例:templates/deployment.yaml 片段
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "prometheus-predictor.fullname" . }}
labels:
{{- include "prometheus-predictor.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
{{- include "prometheus-predictor.selectorLabels" . | nindent 6 }}
template:
metadata:
labels:
{{- include "prometheus-predictor.selectorLabels" . | nindent 8 }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
ports:
- containerPort: {{ .Values.service.port }}
演练技巧: 在容量突增场景下,使用
{{ .Values.resources.requests.cpu | default "500m" }} 确保资源下限可被动态覆盖,避免因默认值过小导致 Pod OOM。
2.3 Values 分层管理
Helm 支持多层级 Values 覆盖,优先级从低到高依次为:
- Chart 内置:
values.yaml中的默认值。 - 父 Chart 覆盖:当 Chart 作为子 Chart 被依赖时,父 Chart 的 values 可覆盖子 Chart 默认值。
- 用户自定义文件:
helm install -f my-values.yaml或helm upgrade --values prod-values.yaml。 - 命令行 --set:
--set replicaCount=5,支持逗号分隔多个键值对。 - 命令行 --set-json:
--set-json 'service.ports=[{"port":80}]',用于复杂 JSON 结构。
常见陷阱:
--set 会覆盖整个列表或 map,而非合并。例如 --set tolerations=[{key:az}] 会替换 values.yaml 中所有 tolerations 条目。在故障域隔离场景中,建议使用 --values 文件进行结构化合并。
2.4 Release 生命周期
一个 Helm Release 从创建到删除经历多个阶段,每个阶段对应一个 Helm 命令。下图展示了完整的生命周期流程:
Release 状态机中的关键状态包括:
- DEPLOYED:当前活跃的 Release,资源已成功应用到集群。
- FAILED:安装或升级过程中发生错误,资源可能部分创建。
- PENDING_INSTALL / PENDING_UPGRADE:操作正在进行中,尚未完成。
- SUPERSEDED:被新版本替换的历史 Release,可通过
helm rollback回退。 - UNINSTALLED:已删除的 Release,默认保留 Release 记录用于审计。
演练关联: 在容量突增演练中,
helm upgrade --reuse-values 可保留已有配置仅更新 replicaCount;若演练导致集群异常,helm rollback 能快速恢复到上一稳定版本,是故障域隔离恢复的关键手段。
2.5 关键命令速查表
| 命令 | 用途 | 演练场景示例 |
|---|---|---|
helm install <name> <chart> |
首次部署 Release | helm install prom-predictor ./chart --values az1-values.yaml |
helm upgrade <name> <chart> |
升级或更新 Release 配置 | helm upgrade prom-predictor ./chart --set replicaCount=10 |
helm rollback <name> <revision> |
回滚到指定历史版本 | helm rollback prom-predictor 3 |
helm history <name> |
查看 Release 修订历史 | helm history prom-predictor |
helm get values <name> |
查看当前 Release 使用的 values | helm get values prom-predictor |
helm uninstall <name> |
删除 Release | helm uninstall prom-predictor |