3. Helm 基础回顾：Chart 结构、模板渲染机制、Values 与依赖管理、Release 生命周期

在深入 Kyverno 与 Helm 的故障域隔离策略冲突排查之前，必须牢固掌握 Helm 的核心运行机制。Helm 作为 Kubernetes 的包管理工具，其 Chart 结构、模板渲染、Values 传递以及 Release 管理构成了策略冲突发生的底层土壤。本节将系统梳理这些基础概念，为后续分析策略注入点与冲突根因奠定基础。

3.1 Chart 目录结构

一个标准的 Helm Chart 是一个遵循特定布局的目录集合。每个 Chart 都包含描述自身元数据的 Chart.yaml 文件，以及用于生成 Kubernetes 资源的模板文件。

3.2 模板渲染机制

Helm 的模板引擎基于 Go 的 text/template 包，并扩展了 50 多个模板函数。渲染过程将 values.yaml 中的值注入到 templates/ 目录下的 Go 模板文件中，最终生成纯 YAML 资源清单。

# 示例：templates/deployment.yaml 中的模板片段
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
  labels:
    {{- include "myapp.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "myapp.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "myapp.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

3.3 Values 与依赖管理

Values 是 Helm 配置的核心，它通过层级结构和优先级规则实现灵活的配置覆盖。依赖管理则允许一个 Chart 引用其他 Chart，形成复合应用。

Values 优先级（从低到高）

1. Chart 内置的 values.yaml：最低优先级，提供默认值。
2. 父 Chart 的 values.yaml：当 Chart 作为子 Chart 被依赖时，父 Chart 的值可以覆盖子 Chart 的默认值。
3. 用户提供的 values 文件：通过 -f 或 --values 参数指定的 YAML 文件。
4. 命令行 --set 参数：最高优先级，直接覆盖所有层级的值。

依赖管理机制

在 Chart.yaml 中使用 dependencies 字段声明依赖，Helm 会解析并下载依赖 Chart 到 charts/ 目录。依赖 Chart 的 Values 可以通过全局值（global）或子 Chart 名称作用域进行传递。

# Chart.yaml 中的依赖声明示例
dependencies:
  - name: redis
    version: "17.3.0"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled
    tags:
      - cache
  - name: postgresql
    version: "12.1.0"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

3.4 Release 生命周期

Release 是 Helm Chart 的一次部署实例。每个 Release 都有唯一的名称和版本号，Helm 通过 Release 对象管理应用的安装、升级、回滚和卸载。

Release 状态转换说明

3.5 模板渲染与策略注入点

理解 Helm 模板渲染的时机和输出，对于定位 Kyverno 策略冲突至关重要。策略引擎在 Helm 提交资源清单后介入，因此冲突发生在渲染后的 YAML 层面。