3. Helm 基础回顾：Chart 结构、Values 管理、模板引擎与 Release 生命周期

在深入 Cilium 网络性能调优之前，必须牢固掌握 Helm —— Kubernetes 生态中最主流的包管理工具。Helm 将复杂的 Kubernetes 资源抽象为可配置、可版本化的 Chart，使得 Cilium 这类系统组件的部署与升级变得标准化。本节将系统回顾 Helm 的四大核心支柱：Chart 目录结构、Values 配置管理、模板引擎语法以及 Release 生命周期。

3.1 Chart 标准目录结构

一个 Helm Chart 是一个按照特定约定组织的文件集合。理解其目录结构是编写和调试 Chart 的基础。以下是一个典型 Chart 的骨架：

my-chart/
├── Chart.yaml          # Chart 元数据（名称、版本、API 版本等）
├── values.yaml         # 默认配置值
├── values.schema.json  # （可选）Values 的 JSON Schema 校验文件
├── charts/             # （可选）子 Chart 依赖（如 Cilium 依赖 etcd-operator）
├── templates/          # 模板文件目录，核心目录
│   ├── _helpers.tpl    # （可选）模板辅助函数/命名模板
│   ├── NOTES.txt       # （可选）安装后的使用说明
│   ├── deployment.yaml
│   ├── service.yaml
│   └── hpa.yaml
└── crds/               # （可选）自定义资源定义（CRD），优先于 templates 安装

3.2 Values 管理：从默认值到多环境覆盖

Values 是 Helm 配置的核心机制。它允许用户在不修改 Chart 源码的情况下，通过注入不同的值来改变部署行为。Values 的优先级从低到高如下：

优先级	来源	说明
1（最低）	values.yaml	Chart 内置的默认值
2	父 Chart 的 values.yaml	当 Chart 作为子 Chart 被依赖时
3	-f values-production.yaml	通过 --values 或 -f 指定的外部 YAML 文件
4（最高）	--set key=value	命令行直接设置，支持逗号分隔和 JSON 路径

在实际的 Cilium 部署中，我们通常维护多套 Values 文件：

• values-dev.yaml：调试级别日志、单副本、资源限制宽松。
• values-staging.yaml：接近生产但保留部分调试端点。
• values-prod.yaml：高可用、资源配额严格、启用 BPF 优化。

3.3 模板引擎与内置对象

Helm 使用 Go 模板语言扩展了 Kubernetes YAML 的灵活性。模板文件通过 {{ }} 双花括号引用 Values 或内置对象。最常用的内置对象包括：

内置对象	类型	典型用途
.Values	map	访问用户提供的配置值
.Release.Name	string	Release 名称，用于资源命名隔离
.Release.Namespace	string	Release 安装的目标命名空间
.Chart	object	Chart.yaml 中的元数据
.Files	object	访问 Chart 内的非模板文件（如配置文件）
.Capabilities	object	Kubernetes 集群版本和 API 能力检测

以下是一个典型的 Deployment 模板片段，展示了模板引擎的核心用法：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-chart.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "my-chart.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "my-chart.name" . }}
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

3.4 Release 生命周期管理

Release 是 Helm 中一个 Chart 的特定部署实例。每次对 Release 的操作（安装、升级、回滚、删除）都会在 Kubernetes 集群中留下记录，存储在 Secret 中（默认位于目标命名空间）。

核心生命周期命令及其作用：

命令	作用	关键参数
helm install	创建新的 Release	--name（Release 名称）、--namespace、-f
helm upgrade	升级现有 Release 或安装（如果不存在）	--install、--reset-values、--reuse-values
helm rollback	回滚到指定历史版本	--recreate-pods、--wait
helm uninstall	删除 Release 及其所有关联资源	--keep-history（保留历史记录）
helm list	列出所有 Release	--all-namespaces、--deployed、--failed
helm history	查看 Release 的修订历史	--max（限制显示条数）

helm upgrade 或 helm rollback 都会生成一个新的修订版本。旧的 deployed 版本变为 superseded，保留在历史中供回滚使用。

3.5 与 Cilium 部署的关联

理解 Helm 基础对于 Cilium 网络性能调优至关重要，原因如下：

• Chart 结构：Cilium 官方 Chart 包含数百个模板文件和数十个可配置参数。了解 _helpers.tpl 中的命名模板有助于定位资源命名规则。
• Values 管理：Cilium 的性能调优参数（如 bandwidthManager、ipam.mode、kubeProxyReplacement）均通过 Values 注入。错误的优先级覆盖可能导致配置失效。
• 模板引擎：Cilium 使用 .Capabilities 对象检测集群版本，动态启用或禁用某些 API 特性（如 EndpointSlice）。
• Release 生命周期：Cilium 升级必须遵循 helm upgrade 流程，错误的回滚可能导致 CNI 配置损坏，影响整个集群的网络连通性。