1. Kustomize 概述：声明式配置管理的核心工具
Kustomize 是 Kubernetes 生态中原生的声明式配置管理工具，自 Kubernetes 1.14 起以 kubectl apply -k 的形式内置集成。它通过 Overlay 层叠机制 实现配置的复用与差异化定制，无需模板引擎或 Chart 打包，完全基于 YAML 的纯声明式操作。
1.1 Kustomize 是什么
Kustomize 的核心思想是：保留原始 YAML 不变，通过分层补丁（Patch）生成最终配置。它不引入新的配置语言，所有操作均通过 kustomization.yaml 文件描述。
关键特性：
- 纯 YAML 原生 — 无模板语法，学习成本低
- 分层 Overlay — base + overlay 结构，环境隔离
- 内置变量替换 — 通过 namePrefix/nameSuffix/commonLabels 实现
- 补丁机制 — strategic merge patch 与 JSON patch 两种模式
- 无需 Helm Tiller — 客户端侧操作，无服务端依赖
1.2 Kustomize 与 Helm 的核心区别
两者虽然都解决 Kubernetes 配置管理问题，但设计哲学截然不同。下表从 8 个关键维度进行对比：
| 对比维度 | Kustomize | Helm |
|---|---|---|
| 设计哲学 | 纯声明式，无模板逻辑 | 模板引擎 + Chart 打包 |
| 配置语言 | 原生 YAML | Go Template + YAML |
| 变量注入 | namePrefix / commonLabels / patches | values.yaml + 模板变量 |
| 环境隔离 | base + overlay 目录结构 | 不同 values 文件 |
| 版本管理 | Git 原生，无额外仓库 | Chart 仓库 + 版本号 |
| 学习曲线 | 低（纯 YAML 操作） | 中（需掌握模板语法） |
| 依赖管理 | 不支持子 Chart 依赖 | 支持 Chart 依赖树 |
| 适用场景 | 内部项目、GitOps、轻量定制 | 应用分发、第三方软件、复杂依赖 |
选型建议： 如果你的团队已经使用 GitOps（如 ArgoCD/Flux），且配置变更主要通过 Git 提交驱动，Kustomize 是更自然的选择。Helm 更适合需要对外发布、版本化、支持复杂依赖的应用场景。
1.3 声明式配置管理理念
Kustomize 是 Kubernetes 声明式理念在配置管理层面的延伸。其核心原则包括：
- 期望状态描述 — 只描述"最终要什么"，不描述"如何达到"
- 幂等性 — 同一配置多次应用结果一致
- 可组合性 — 基础配置与差异化配置分离，通过层叠组合
- 可审计性 — 所有变更通过 Git 记录，配置即代码
1.4 典型目录结构示例
一个标准 Kustomize 项目的目录布局如下，清晰体现 base + overlay 的分层思想：
my-app/
├── base/ # 基础配置（通用）
│ ├── kustomization.yaml # 声明引用的资源
│ ├── deployment.yaml # 通用 Deployment
│ └── service.yaml # 通用 Service
├── overlays/
│ ├── development/ # 开发环境 Overlay
│ │ ├── kustomization.yaml
│ │ └── patches/
│ │ └── replicas_patch.yaml # 副本数补丁
│ └── production/ # 生产环境 Overlay
│ ├── kustomization.yaml
│ └── patches/
│ ├── replicas_patch.yaml
│ └── resources_patch.yaml # 资源限制补丁
└── README.md
常见误区： 不要将 Kustomize 与 Helm 对立看待。实际项目中两者可以互补——Helm 负责应用分发和版本管理，Kustomize 负责环境差异化定制。ArgoCD 和 Flux 均同时支持两种工具。