Helm vs Kustomize

概述

在 Kubernetes 生态中，应用的配置管理是持续交付流水线的核心环节。Helm 和 Kustomize 是两种主流的配置管理工具，但它们的设计哲学截然不同。Helm 采用模板渲染（Template Rendering）模式，将配置视为参数化的可安装包；Kustomize 则采用声明式覆盖（Declarative Overlay）模式，以基础配置加补丁的方式实现环境差异化。理解两者的差异对于 SRE 团队选择合适的部署工具至关重要，因为这直接影响变更安全性、回滚可靠性以及配置漂移（Configuration Drift）的防控能力。

Helm：模板化方法

Helm 是 Kubernetes 的包管理器，其核心抽象是 Chart。一个 Chart 是一组预定义的 Kubernetes 资源模板，通过 values.yaml 文件注入参数，最终渲染为可部署的 manifest。

Chart 结构

一个标准的 Helm Chart 目录结构如下：

my-app/
├── Chart.yaml          # Chart 元数据（名称、版本、依赖）
├── values.yaml         # 默认配置值
├── templates/          # Go template 模板文件
│   ├── deployment.yaml
│   ├── service.yaml
│   └── _helpers.tpl    # 模板辅助函数
└── charts/             # 子 Chart 依赖

核心机制

  • values.yaml：定义所有可配置参数的默认值。部署时可通过 -f custom-values.yaml 或 --set key=value 覆盖。
  • Releases：每次 helm install 或 helm upgrade 都会创建一个 Release，记录在集群中（默认以 Secret 形式存储），支持通过 helm history 查看部署历史。
  • Rollback：helm rollback <release> <revision> 可快速回滚到任意历史版本，Release 的 revision 机制为回滚提供了可靠的基础。
# 安装
helm install my-app ./my-app -f production-values.yaml

# 升级
helm upgrade my-app ./my-app -f production-values.yaml --set image.tag=v2.1.0

# 回滚到上一个版本
helm rollback my-app 1

Kustomize：覆盖式方法

Kustomize 内置于 kubectl（自 v1.14 起），其设计哲学是无模板的配置定制。它通过 Base 和 Overlay 的分层结构，使用 Strategic Merge Patch 和 JSON Patch 来实现环境差异化。

Base/Overlay 结构

├── base/
│   ├── kustomization.yaml
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── replica-patch.yaml
    ├── staging/
    │   └── kustomization.yaml
    └── production/
        ├── kustomization.yaml
        └── resource-patch.yaml

核心机制

  • Base：包含原始的、未经修改的 Kubernetes 资源文件，是所有环境共享的共同基础。
  • Overlay：引用 Base 并定义针对特定环境的修改。Overlay 不直接修改 Base 文件，而是通过 Patch（Strategic Merge Patch 或 JSON 6902 Patch）叠加变更。
  • Generators：支持通过 configMapGenerator 和 secretGenerator 自动生成 ConfigMap 和 Secret，并自动添加哈希后缀以触发滚动更新。
# 构建生产环境 manifest
kubectl kustomize overlays/production/

# 直接应用
kubectl apply -k overlays/production/

对比分析

维度HelmKustomize
学习曲线较陡峭，需掌握 Go Template 语法较平缓，YAML 原生，易于上手
模板复杂度高，模板逻辑可能变得难以维护低，无模板语言，配置即 YAML
Secret 管理依赖外部工具（Sealed Secrets、Vault）secretGenerator 支持本地生成
生态系统丰富，Artifact Hub 提供大量预制 Chart较小，依赖社区 Base 配置
版本管理原生 Release 和 Revision 机制无内置版本管理，依赖 Git
依赖管理Chart.yaml 声明依赖并自动拉取无原生依赖管理
模板复用支持 Library Chart 和子 Chart通过 Base 引用实现复用
原生集成需安装 Helm CLI内置于 kubectl

SRE 视角

升级安全性

Helm 的 Release 机制提供了内置的升级安全网：每次升级都会记录完整的 manifest 快照，使得升级失败时可以快速回滚。然而，Helm 的模板渲染是全量的，复杂的条件逻辑可能导致意外的资源变更。

Kustomize 的 Overlay 模式在升级时更加可控——变更范围完全由 Patch 定义，SRE 可以精确审查每次变更的影响面。但由于缺乏内置的版本管理，回滚操作完全依赖 Git 历史和 CI/CD 流水线的质量。

回滚可靠性

Helm 的 helm rollback 是可靠的原子操作，适合紧急回滚场景。Kustomize 的回滚则需要 git revert 加重新部署，在时间紧迫的故障恢复中可能增加 MTTR。

配置漂移防控

配置漂移是 SRE 的核心关注点。Helm 通过 helm diff 插件可以在升级前预览变更，有效防止意外修改。Kustomize 的声明式特性天然适合 GitOps 工作流，结合 Argo CD 或 Flux 的自动同步机制，可以从源头遏制配置漂移。

选择建议

  • 选择 Helm：当应用本身需要作为可分发的包管理（如开源项目、内部平台组件），或团队需要可靠的 Release 管理和一键回滚能力时。
  • 选择 Kustomize：当管理同一应用的多环境配置差异，或团队偏好纯声明式、无模板的 GitOps 工作流时。
  • 混合使用：许多团队采用 Helm 渲染基础 manifest，再通过 Kustomize Overlay 进行环境定制的混合策略，兼顾两者优势。