📚 课程目录第4章 Helm包管理基础

4. Helm 包管理基础：Helm 架构、Chart 结构、模板引擎与 Values 文件的作用

在云原生安全巡检场景中，Helm 是部署 eBPF 节点代理（如 Cilium、Pixie、Falco）的事实标准工具。理解 Helm 的架构与 Chart 结构，是后续编写安全巡检 Helm Chart 和集成流量审计的基础。本节从 Helm 整体架构出发，逐步拆解 Chart 目录、模板引擎与 Values 文件的核心机制。

4.1 Helm 架构：Tiller 已死，Client-Only 时代

Helm v3 彻底移除了服务端组件 Tiller，采用纯客户端架构。这使得 Helm 与 Kubernetes API Server 直接交互，大幅提升了安全性和部署灵活性。

  架构要点： Helm v3 通过 helm install 命令在本地渲染模板，然后通过 Kubernetes API 直接创建资源。不再需要集群内的 Tiller 服务，避免了权限滥用风险。

4.2 Chart 结构：标准目录与核心文件

一个 Helm Chart 是一个按照标准目录结构组织的文件集合。每个文件都有明确的职责，共同构成可部署的 Kubernetes 应用包。

文件/目录	是否必需	作用说明
`Chart.yaml`	是	Chart 元数据：名称、版本、API 版本、描述、关键字等
`values.yaml`	是	默认配置值，供模板引擎引用，用户可覆盖
`templates/`	是	存放 Go 模板文件，渲染后生成 Kubernetes 资源清单
`charts/`	否	子 Chart 依赖，存放被依赖的其他 Chart
`crds/`	否	自定义资源定义（CRD），在模板渲染前安装
`templates/NOTES.txt`	否	安装成功后输出的使用说明文本
`README.md`	否	Chart 的使用文档，非 Helm 强制但推荐

安全巡检场景提示： 在编写 eBPF 节点代理的 Chart 时，crds/ 目录常用于定义 ClusterTracingPolicy 或 NetworkPolicy 等 CRD，确保在部署代理前 CRD 已就绪。

4.3 模板引擎：Go Template 与 Sprig 函数库

Helm 使用 Go 标准库的 text/template 作为模板引擎，并集成了 Sprig 函数库（提供 100+ 额外模板函数）。模板引擎将 values.yaml 中的值注入到 templates/ 目录下的 YAML 文件中，生成最终的 Kubernetes 资源清单。

4.3.1 核心模板语法

语法	说明	示例
`{{ .Values.key }}`	引用 values.yaml 中的值	`image: {{ .Values.image.repository }}:{{ .Values.image.tag }}`
`{{- if condition }} ... {{- end }}`	条件判断，`-` 用于去除空白	`{{- if .Values.rbac.create }} ... {{- end }}`
`{{- range $i, $v := .List }}`	遍历列表或字典	`{{- range .Values.extraEnv }} ... {{- end }}`
`{{ .Chart.Name }}`	内置对象，引用 Chart.yaml 字段	`name: {{ .Chart.Name }}-agent`
`{{ .Release.Name }}`	内置对象，引用 Release 名称	`app.kubernetes.io/instance: {{ .Release.Name }}`

4.3.2 模板渲染示例

以下是一个典型的 Deployment 模板片段，展示如何结合 Values 和内置对象生成资源名称与标签：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-{{ .Chart.Name }}
  labels:
    app.kubernetes.io/name: {{ .Chart.Name }}
    app.kubernetes.io/instance: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .Chart.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          env:
            {{- range .Values.extraEnv }}
            - name: {{ .name }}
              value: {{ .value | quote }}
            {{- end }}

注意： 模板中的 | quote 是 Sprig 函数，用于给字符串添加引号。在 eBPF 安全巡检场景中，extraEnv 常用于传递节点名称、审计规则路径等动态配置。

4.4 Values 文件：配置分层与覆盖机制

Values 文件是 Helm 配置的核心，它定义了 Chart 的所有可配置参数。Helm 支持多层 Values 覆盖，优先级从低到高依次为：Chart 内置 values.yaml → 父 Chart 的 values.yaml → 用户提供的 -f 文件 → --set 命令行参数。

4.4.1 典型 Values 文件结构

# values.yaml — 默认配置
replicaCount: 2

image:
  repository: docker.io/ebpf-agent
  tag: "1.0.0"
  pullPolicy: IfNotPresent

rbac:
  create: true
  serviceAccountName: ebpf-agent-sa

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 200m
    memory: 256Mi

extraEnv:
  - name: NODE_NAME
    valueFrom:
      fieldRef:
        fieldPath: spec.nodeName
  - name: AUDIT_RULES_PATH
    value: "/etc/ebpf-audit/rules.yaml"

nodeSelector:
  kubernetes.io/os: linux

tolerations:
  - operator: Exists

4.4.2 覆盖优先级示例

覆盖层级	命令/文件	优先级
Chart 默认值	`chart/values.yaml`	最低（基础值）
父 Chart 值	父 Chart 的 `values.yaml`	低
用户 Values 文件	`helm install -f my-values.yaml`	中
命令行参数	`--set image.tag=latest`	最高（覆盖所有）

  安全巡检最佳实践： 将 eBPF 代理的审计规则路径、节点亲和性、容忍度等安全相关配置放在独立的 values-security.yaml 文件中，通过 -f 参数注入，避免修改 Chart 内置默认值。

4.5 Helm 部署生命周期与安全巡检集成

在 eBPF 节点池安全巡检场景中，Helm 的 install、upgrade、rollback 操作与安全策略的版本管理紧密相关。每次部署或更新 eBPF 代理时，Helm 都会记录 Release 历史，便于审计回滚。

install：部署 eBPF 代理，同时注入初始审计规则（通过 Values 文件）。 • upgrade：更新审计规则或代理版本，Helm 自动执行滚动更新，不影响已有连接。 • rollback：当新规则导致误报或性能下降时，快速回滚到上一个稳定版本。

4.6 本章小结

Helm v3 架构：纯客户端，无 Tiller，直接与 Kubernetes API 交互，安全性更高。
Chart 结构：Chart.yaml、values.yaml、templates/ 是核心三要素，crds/ 和 charts/ 用于扩展。
模板引擎：Go Template + Sprig 函数库，支持条件、循环、变量引用，渲染出最终 YAML。
Values 文件：多层覆盖机制，从默认值到 --set 参数，优先级逐级递增。
安全巡检集成：Helm 的 install/upgrade/rollback 为 eBPF 代理的审计规则版本管理提供了标准化流程。