3. Helm Chart 基础回顾:Chart 结构、模板引擎、Values 文件、依赖管理
在多集群变更门禁流水线中,Helm Chart 是环境配置的标准化载体。理解 Chart 的内部结构、模板渲染机制、Values 分层以及依赖管理,是构建可复用的环境配置基座的前提。本节从四个核心维度展开回顾。
3.1 Chart 标准目录结构
一个标准的 Helm Chart 遵循固定的目录布局,流水线在打包、签名、分发时依赖此结构进行元数据解析与资源组装。
| 路径 / 文件 | 必需 | 说明 |
|---|---|---|
Chart.yaml |
是 | Chart 元数据:名称、版本、API 版本、描述、关键字 |
values.yaml |
是 | 默认配置值,供模板引擎引用 |
templates/ |
是 | Go 模板文件,渲染后生成 Kubernetes 资源清单 |
charts/ |
否 | 子 Chart 包(依赖管理,手动或 helm dependency update 填充) |
crds/ |
否 | 自定义资源定义(CRD),在模板渲染前安装 |
templates/NOTES.txt |
否 | 安装成功后输出的使用说明 |
templates/tests/ |
否 | 测试 Pod 模板,用于 helm test |
流水线集成要点: 门禁流水线在 Chart 打包前应校验
Chart.yaml 中的 version 与 appVersion 是否遵循语义化版本规范,避免因元数据缺失导致仓库索引失败。
3.2 模板引擎与渲染上下文
Helm 使用 Go text/template 扩展了 60+ 内置函数(Sprig 库),并注入预定义对象:.Values、.Release、.Chart、.Files、.Capabilities。模板文件通过 {{ .Values.replicaCount }} 引用 Values 中的值,支持管道、条件、循环、命名模板。
# templates/deployment.yaml 示例片段
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "myapp.fullname" . }}
labels:
app.kubernetes.io/name: {{ include "myapp.name" . }}
helm.sh/chart: {{ include "myapp.chart" . }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app.kubernetes.io/name: {{ include "myapp.name" . }}
template:
metadata:
labels:
app.kubernetes.io/name: {{ include "myapp.name" . }}
spec:
containers:
- name: {{ .Chart.Name }}
image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
ports:
- containerPort: {{ .Values.service.port }}
命名模板复用: 使用
define 和 template 或 include 提取公共标签片段(如 myapp.labels),减少重复代码,提升多环境 Chart 的可维护性。
3.3 Values 文件分层与合并策略
流水线在多集群场景下通常维护多套 Values 文件:values.yaml(默认)、values-staging.yaml、values-production.yaml。Helm 在 helm install/upgrade 时按以下优先级合并(低 → 高):
- Chart 内置
values.yaml— 基础默认值 - 父 Chart 的
values.yaml— 当作为子 Chart 时 -f指定的文件 — 按顺序叠加,后文件覆盖前文件--set命令行参数 — 最高优先级,适合流水线动态注入
# 流水线典型命令示例
helm upgrade --install myapp ./myapp-chart \
--namespace myapp-staging \
-f values.yaml \
-f values-staging.yaml \
--set image.tag=${CI_COMMIT_SHORT_SHA} \
--set global.clusterName=${CLUSTER_NAME}
避坑:
--set 传入复杂结构(如数组、嵌套对象)时容易出错。建议流水线只注入简单标量(镜像标签、副本数),复杂环境差异通过 -f 引用独立 Values 文件管理。
3.4 依赖管理与子 Chart 集成
多集群环境配置常将基础设施组件(Redis、PostgreSQL、Ingress Controller)封装为子 Chart,通过 Chart.yaml 的 dependencies 字段声明依赖。
# Chart.yaml 依赖声明示例
dependencies:
- name: redis
version: "~17.0.0"
repository: "https://charts.bitnami.com/bitnami"
condition: redis.enabled
tags:
- cache
- name: postgresql
version: "~12.0.0"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
tags:
- database
依赖管理的关键命令与流水线集成点:
| 命令 | 作用 | 流水线阶段建议 |
|---|---|---|
helm dependency update |
根据 Chart.yaml 下载依赖包到 charts/ 目录,生成 Chart.lock |
打包前执行,确保依赖版本锁定 |
helm dependency build |
从 Chart.lock 重建依赖,不更新版本 |
离线环境或需要可复现构建时使用 |
helm dependency list |
列出当前依赖状态(名称、版本、仓库、状态) | 门禁检查:验证所有依赖状态为 ok |
多集群依赖策略: 对于生产集群,建议将子 Chart 的
condition 与全局 Values 绑定(如 global.redis.enabled),通过顶层 Values 开关控制是否启用外部依赖,避免每个环境重复修改子 Chart 配置。
3.5 多集群 Values 覆盖最佳实践
在门禁流水线中,不同集群的环境差异通过 Values 文件分层隔离,避免 Chart 模板内硬编码集群标识。推荐的文件组织方式:
charts/myapp/
├── Chart.yaml
├── values.yaml # 全局默认值
├── values-staging.yaml # 预发集群覆盖
├── values-production.yaml # 生产集群覆盖
├── values-dr.yaml # 灾备集群覆盖
└── templates/
└── ...
全局 Values 设计: 在
values.yaml 中定义 global.clusterName、global.region、global.environment 等顶层字段,子 Chart 和模板通过 .Values.global 统一读取,确保多集群配置的可追溯性。