2. Helm 基础回顾:Helm 架构、Chart 结构、模板引擎、Release 管理核心概念

在深入节点池 Chart 更新触发配置巡检流程之前,必须重新夯实 Helm 的核心知识体系。Helm 作为 Kubernetes 的包管理工具,其架构设计、Chart 结构、模板引擎以及 Release 管理机制,是后续所有自动化巡检与更新操作的理论基石。本节将系统梳理这四个核心概念,确保你在后续章节中能够准确理解 Helm 的行为逻辑。

2.1 Helm 架构:客户端与库的协作

Helm 采用客户端-库(Client-Library)架构,而非传统的客户端-服务端架构。自 Helm 3 起,移除了 Tiller(服务端组件),架构变得更加简洁、安全。

架构核心变化: Helm 3 移除了 Tiller,直接通过 Kubernetes API Server 与集群交互。Release 信息以 Secret 资源形式存储在集群的命名空间中,不再依赖服务端组件,大幅提升了安全性和权限控制粒度。
Helm 3 架构图 Helm 3 架构:客户端直连 API Server 用户 / CI 系统 Helm 客户端 (CLI) Kubernetes API Server helm install/upgrade Kubernetes API 调用 Kubernetes 集群 Release Secret (命名空间) 说明: Helm 客户端直接通过 kubeconfig 与 API Server 通信,将 Chart 渲染为 Kubernetes 资源清单并提交。 Release 的版本历史以 Secret 形式保存在目标命名空间中,不再需要 Tiller 服务端。

2.2 Chart 结构:标准化的应用打包格式

Chart 是 Helm 应用打包的核心单元,遵循标准化的目录结构。理解 Chart 结构是编写和修改节点池 Chart 的前提。

文件/目录 是否必需 说明
Chart.yaml 是 Chart 的元数据文件,包含名称、版本、描述、API 版本等。
values.yaml 是 默认配置值文件,用户可通过 --set 或自定义 values 文件覆盖。
templates/ 是 存放 Go 模板文件,渲染后生成 Kubernetes 资源清单。
charts/ 否 存放子 Chart(依赖 Chart)的目录。
crds/ 否 存放自定义资源定义(CRD)的 YAML 文件,Helm 会优先安装。
README.md 推荐 Chart 的使用说明文档。
templates/NOTES.txt 否 安装成功后输出的提示信息模板。
节点池 Chart 实践提示: 在节点池场景中,values.yaml 通常定义节点池名称、实例规格、初始节点数、Kubernetes 版本等参数。templates/ 目录下会包含 nodePool.yaml、cluster.yaml 等资源模板。

2.3 模板引擎:Go 模板与内置函数

Helm 使用 Go 模板语言对 Chart 中的资源文件进行动态渲染。模板引擎是 Helm 实现“一次编写,到处配置”的核心能力。

模板文件通常包含以下元素:

  • 模板指令:使用 {{ }} 包裹,用于执行逻辑控制、变量引用和函数调用。
  • 内置对象:Values(用户配置值)、Release(Release 元数据)、Chart(Chart.yaml 内容)、Files(Chart 内文件访问)、Capabilities(集群能力信息)。
  • 管道函数:如 quote、default、upper、indent、nindent 等,用于格式化输出。
  • 流程控制:if/else、with、range,用于条件渲染和循环遍历。
# 一个典型的模板片段示例 (templates/nodePool.yaml)
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: {{ .Release.Name }}-{{ .Values.nodePoolName }}
  namespace: {{ .Release.Namespace }}
  labels:
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount | default 3 }}
  template:
    spec:
      version: {{ .Values.kubernetesVersion | quote }}
      {{- if .Values.customLabels }}
      labels:
        {{- range $key, $value := .Values.customLabels }}
        {{ $key }}: {{ $value | quote }}
        {{- end }}
      {{- end }}
模板渲染避坑: 注意 YAML 缩进敏感性。使用 nindent 函数(自动换行并缩进)比 indent 更安全。避免在模板中直接拼接字符串导致 YAML 解析错误。

2.4 Release 管理:版本化部署的核心机制

Release 是 Helm 管理的核心抽象,代表 Chart 的一次独立部署实例。每次 helm install、helm upgrade 或 helm rollback 操作都会生成一个新的 Release 版本。

Release 生命周期与版本管理 Release 生命周期与版本管理 helm install Release v1 helm upgrade Release v2 helm upgrade Release v3 helm rollback helm uninstall Release 已删除 每个 Release 版本都对应一个 Secret 资源,存储在目标命名空间中。Helm 默认保留最近 10 个版本的历史记录(可通过 --history-max 配置)。

Release 管理的关键操作与概念:

操作命令 功能描述 对 Release 版本的影响
helm install 首次部署 Chart,创建 Release 生成 Release v1
helm upgrade 升级 Release 到新版本 生成 Release v2, v3, ...
helm rollback 回滚到之前的 Release 版本 基于目标版本生成新的 Release 版本(非覆盖)
helm history 查看 Release 的版本历史 列出所有版本号、状态、修订时间
helm uninstall 卸载 Release 标记 Release 为已删除,可选择保留历史记录
helm list 列出当前命名空间下的所有 Release 显示 Release 名称、状态、Chart 版本、App 版本
节点池巡检场景关联: 在后续的配置巡检流程中,我们将利用 helm history 和 helm get values 命令获取 Release 的配置变更历史,与节点池的实际运行状态进行比对,从而发现配置漂移或未生效的更新。