2. Helm 基础回顾：Chart 结构、模板引擎、Values 与依赖管理、Helm v3 特性
在深入冷启动削峰与 Sigstore 集成之前，必须夯实 Helm 的核心基础。本章将系统梳理 Chart 的物理结构、模板渲染机制、Values 传递链路、依赖管理策略以及 Helm v3 的关键变更。这些知识是后续所有调优与安全实践的前提。
2.1 Chart 标准目录结构
一个标准的 Helm Chart 遵循固定的目录布局，每个文件或目录都有明确的语义。理解这一结构是编写可维护 Chart 的第一步。
| 路径 / 文件 | 必需 | 说明 |
|---|---|---|
Chart.yaml |
是 | Chart 元数据：名称、版本、API 版本、描述、关键字等 |
values.yaml |
是 | 默认配置值，供模板引用 |
templates/ |
是 | Go 模板文件，渲染后生成 Kubernetes 资源清单 |
charts/ |
否 | 子 Chart（依赖）的打包目录 |
crds/ |
否 | 自定义资源定义（CRD），在模板渲染前安装 |
templates/NOTES.txt |
否 | 安装成功后输出的使用说明 |
templates/tests/ |
否 | 测试 Pod 模板，用于验证部署 |
讲师提示：
crds/ 目录中的 CRD 由 Helm v3 特殊处理——它们会在 templates/ 渲染之前安装，且不受 --wait 或 --atomic 影响。这是设计 Operator Chart 时的关键约束。
2.2 模板引擎与渲染管线
Helm 使用 Go 模板引擎（text/template）配合 Sprig 函数库进行资源渲染。渲染过程分为三个阶段：
- 值合并：将
values.yaml、用户传入的--set/-f文件、子 Chart 值按优先级合并。 - 模板解析：遍历
templates/目录，执行{{ .Values... }}、{{ include }}、{{ range }}等指令。 - 输出校验：将渲染结果以 YAML 格式输出，Helm 内置对 Kubernetes 资源类型的轻量校验。
核心函数速查：
# 引用值
{{ .Values.replicaCount }}
# 模板嵌套（define / include）
{{ include "mychart.labels" . }}
# 流程控制
{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
{{- end }}
# 管道与函数
{{ .Values.image.tag | default "latest" | quote }}2.3 Values 优先级与作用域
Helm 的 Values 系统遵循严格的优先级规则。理解这一规则可以避免生产环境中值覆盖混乱的问题。
| 优先级（高 → 低） | 来源 | 示例 |
|---|---|---|
| 1 | --set / --set-string |
--set image.tag=v2.0 |
| 2 | -f 指定的自定义 values 文件 |
-f prod-values.yaml |
| 3 | Chart 内嵌的 values.yaml |
Chart 包默认值 |
| 4 | 子 Chart 的 values.yaml |
依赖库的默认值 |
常见陷阱： 使用
--reuse-values 时，Helm 会跳过值合并，直接复用上一次部署的 Values。这在 CI/CD 流水线中极易导致环境差异，不推荐在生产场景使用。
2.4 依赖管理：Chart.yaml 与 helm dependency
Helm v3 使用 Chart.yaml 中的 dependencies 字段声明依赖，替代了 v2 的 requirements.yaml。依赖管理流程如下：
# Chart.yaml 依赖声明示例
dependencies:
- name: postgresql
version: "12.1.0"
repository: "https://charts.bitnami.com/bitnami"
condition: postgresql.enabled
tags:
- database
- name: redis
version: "17.0.0"
repository: "https://charts.bitnami.com/bitnami"
condition: redis.enabled常用命令：
helm dependency list— 查看当前依赖状态helm dependency update— 下载依赖到charts/目录并生成Chart.lockhelm dependency build— 基于Chart.lock重建依赖，确保版本锁定
讲师建议： 始终将
Chart.lock 纳入版本控制。这能确保团队所有成员和 CI 环境使用完全相同的依赖版本，避免“在我机器上能跑”的问题。
2.5 Helm v3 关键特性
Helm v3 相比 v2 做了大量架构性改进，直接影响部署策略和安全模型。以下是必须掌握的核心变更：
| 特性 | Helm v2 | Helm v3 | 影响 |
|---|---|---|---|
| Tiller | 集群内服务端组件 | 已移除，纯客户端架构 | 消除 RBAC 安全风险，简化运维 |
| Release 存储 | ConfigMap（默认） | Secret（默认） | 敏感信息默认加密存储 |
| 命名空间作用域 | Release 名称全局唯一 | Release 名称按命名空间隔离 | 同一集群可跨命名空间复用名称 |
| CRD 处理 | 需手动管理 | crds/ 目录自动安装 |
Operator Chart 部署更可靠 |
| Chart API 版本 | apiVersion: v1 |
apiVersion: v2 |
v2 强制要求依赖声明格式 |
| OCI 支持 | 实验性 | 稳定（v3.8+） | Chart 可存储于 OCI 兼容仓库 |
2.6 实践要点：从 v2 迁移到 v3
对于仍在使用 Helm v2 的团队，迁移到 v3 是必要步骤。以下是关键操作清单：
- 移除 Tiller：
kubectl delete deployment tiller-deploy -n kube-system - 转换 Release 数据：使用
helm 2to3插件将 v2 Release 迁移到 v3 格式 - 更新 Chart.yaml：将
apiVersion改为v2，重写dependencies字段 - 验证模板：v3 对模板语法校验更严格，使用
helm template --validate提前发现错误 - 调整 CI/CD：移除
--tiller-namespace参数，改用--namespace
迁移检查命令：
# 查看当前 Helm 版本
helm version
# 使用 2to3 插件迁移单个 Release
helm 2to3 convert my-release
# 验证 Chart 兼容性
helm lint mychart/