3. Helm 基础回顾:Chart 结构、模板引擎、Values 配置、Release 管理、依赖管理
在深入 eBPF 节点池巡检的 Helm 部署之前,有必要系统回顾 Helm 的核心概念。Helm 是 Kubernetes 的包管理工具,它将应用及其依赖打包为 Chart,通过 模板引擎 动态生成 Kubernetes 资源清单,利用 Values 实现配置分离,通过 Release 管理部署实例,并借助 依赖管理 处理组件间的关联。本节将逐一拆解这五个核心模块。
3.1 Chart 结构:标准化的应用打包规范
一个 Helm Chart 是一个遵循特定目录结构的文件集合。以下是一个典型 Chart 的目录布局:
my-chart/
├── Chart.yaml # Chart 元数据(名称、版本、描述等)
├── values.yaml # 默认配置值
├── values.schema.json # (可选)Values 的 JSON Schema 校验文件
├── charts/ # (可选)子 Chart 依赖包
├── templates/ # Kubernetes 资源模板目录
│ ├── NOTES.txt # (可选)部署后的使用说明
│ ├── _helpers.tpl # (可选)模板辅助函数
│ ├── deployment.yaml
│ ├── service.yaml
│ └── hpa.yaml
└── crds/ # (可选)自定义资源定义(CRD)
关键点:
templates/ 目录下的文件会被 Helm 模板引擎渲染;charts/ 目录存放被依赖的子 Chart;crds/ 中的 CRD 会在安装时优先创建。
3.2 模板引擎:Go Template 与 Sprig 函数库
Helm 使用 Go 语言内置的 text/template 作为模板引擎,并集成了 Sprig 函数库(超过 70 个附加函数)。模板文件以 .yaml 或 .tpl 结尾,通过双花括号 {{ }} 插入动态值。
核心语法示例:
{{- /* 注释:获取 Values 中的 image.repository */ -}}
image: {{ .Values.image.repository }}:{{ .Values.image.tag | default "latest" }}
{{- /* 条件判断:根据 .Values.service.enabled 决定是否创建 Service */ -}}
{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
...
{{- end }}
{{- /* 循环:遍历 .Values.ports 列表生成多个端口映射 */ -}}
{{- range .Values.ports }}
- port: {{ .port }}
targetPort: {{ .targetPort }}
{{- end }}
模板调试技巧: 使用
helm template . 可以在本地渲染模板并输出 YAML,无需实际安装;使用 helm lint . 可以检查 Chart 语法和模板错误。
3.3 Values 配置:分层覆盖与作用域
Values 是 Helm 配置分离的核心机制。默认值定义在 values.yaml 中,用户可以通过多个层级覆盖:
| 优先级(从低到高) | 配置来源 | 说明 |
|---|---|---|
| 1 | values.yaml |
Chart 内置的默认值 |
| 2 | 子 Chart 的 values.yaml |
父 Chart 可覆盖子 Chart 的默认值 |
| 3 | -f values-custom.yaml |
用户自定义的外部 Values 文件 |
| 4 | --set key=value |
命令行直接设置,支持逗号分隔多个值 |
| 5 | --set-json '{"key":"val"}' |
JSON 格式的复杂值注入(Helm 3.10+) |
Values 作用域规则:
- 父 Chart 通过
values.yaml中的子Chart名称:字段传递值给子 Chart。 - 全局值通过
global:字段定义,所有子 Chart 均可访问。 - 模板中通过
.Values访问当前 Chart 的 Values,通过.Values.global访问全局值。
3.4 Release 管理:部署实例的生命周期
Release 是 Helm 中一个 Chart 的部署实例。每次 helm install 或 helm upgrade 都会创建一个 Release 版本。Helm 在 Kubernetes 集群的 kube-system 命名空间中存储 Release 的元数据(Secret 或 ConfigMap)。
常用 Release 管理命令:
# 安装一个 Release
helm install my-release ./my-chart -n monitoring
# 升级 Release(支持回滚)
helm upgrade my-release ./my-chart -f values-prod.yaml
# 查看 Release 历史
helm history my-release -n monitoring
# 回滚到指定版本
helm rollback my-release 2 -n monitoring
# 卸载 Release
helm uninstall my-release -n monitoring
注意: Helm 3 移除了 Tiller,Release 信息直接存储在集群中(Secret 类型为
helm.sh/release.v1)。默认保留 10 个历史版本,可通过 --history-max 调整。
3.5 依赖管理:子 Chart 与条件加载
Helm 通过 Chart.yaml 中的 dependencies 字段声明依赖。依赖可以是本地路径、HTTP URL 或 Helm 仓库中的 Chart。
依赖声明示例(Chart.yaml):
dependencies:
- name: prometheus
version: "15.0.0"
repository: "https://prometheus-community.github.io/helm-charts"
condition: prometheus.enabled # 条件加载
tags:
- monitoring
- name: grafana
version: "6.50.0"
repository: "https://grafana.github.io/helm-charts"
condition: grafana.enabled
tags:
- monitoring
依赖管理命令:
# 下载依赖到 charts/ 目录
helm dependency update ./my-chart
# 构建依赖(生成 Chart.lock 文件)
helm dependency build ./my-chart
# 查看依赖树
helm dependency list ./my-chart
最佳实践: 在 eBPF 节点池巡检场景中,建议将 Prometheus、Grafana 等监控组件作为条件依赖,通过
--set prometheus.enabled=false 在已有监控环境的集群中跳过安装,避免资源冲突。
3.6 核心概念对比总结
| 概念 | 类比 | 关键文件/命令 | 在 eBPF 巡检中的角色 |
|---|---|---|---|
| Chart | 应用安装包(如 .deb/.rpm) | Chart.yaml |
打包 eBPF DaemonSet、ServiceMonitor、告警规则 |
| 模板引擎 | 代码生成器 | templates/*.yaml |
根据节点池大小动态生成 eBPF 采集器副本数 |
| Values | 配置文件 | values.yaml |
配置 eBPF 程序挂载点、采集间隔、告警阈值 |
| Release | 运行中的实例 | helm install/upgrade |
管理不同集群环境的 eBPF 巡检部署版本 |
| 依赖管理 | 包依赖(如 npm/pip) | dependencies 字段 |
自动安装 Prometheus Operator、Grafana 等依赖 |