2. Helm 基础回顾：Chart 结构、模板引擎、Values 文件、Release 管理

在深入 Helm 与 OPA 集成之前，必须牢固掌握 Helm 的核心概念。本节将系统回顾 Chart 的目录结构、Go 模板引擎的工作机制、Values 文件的层级覆盖规则以及 Release 的生命周期管理。这些基础是后续定位延迟问题的前提。

2.1 Chart 标准目录结构

一个 Helm Chart 是一个按照特定约定组织的文件集合。标准结构如下：

2.2 模板引擎核心机制

Helm 使用 Go 的 text/template 引擎，并扩展了 Sprig 函数库。模板引擎的工作分为三个阶段：解析 → 取值 → 渲染。

• 解析（Parse）：读取 templates/ 下的所有文件，识别 {{ }} 标记。
• 取值（Evaluate）：将 .Values、.Release、.Chart、.Files 等内置对象注入模板上下文。
• 渲染（Render）：生成最终的 Kubernetes YAML 清单。

常用模板语法速查：

2.3 Values 文件层级与覆盖规则

Helm 允许通过多个来源提供 Values，优先级从低到高依次为：

1. Chart 内置 values.yaml（最低优先级）
2. 父 Chart 的 Values（当作为子 Chart 时）
3. 用户提供的 -f 文件（可指定多个，后覆盖前）
4. 命令行 --set 参数（最高优先级）

合并策略是深度合并（deep merge）：相同层级覆盖，不同层级保留。以下是一个典型的覆盖示例：

# values.yaml（默认）
image:
  repository: nginx
  tag: stable

# custom-values.yaml（用户提供）
image:
  tag: 1.25.0

# 最终合并结果
image:
  repository: nginx
  tag: 1.25.0

2.4 Release 管理生命周期

Release 是 Chart 的一次部署实例。Helm 通过 Release 记录（存储在 Secret 或 ConfigMap 中）追踪每次操作。核心操作包括：

每次操作都会生成一个新的修订版本（Revision），从 1 开始递增。Helm 默认保留最近 10 个修订版本的记录。

2.5 Helm 核心工作流（内联 SVG）

下图展示了从 Chart 到 Release 的完整渲染与部署流程，以及 OPA 策略的介入点：

2.6 常见延迟场景速查表

以下表格总结了 Helm 基础环节中可能引发延迟的典型场景，后续章节将逐一展开：