📚 课程目录第1章 Kustomize概述

1. Kustomize 概述

1.1 Kustomize 是什么

Kustomize 是 Kubernetes 生态中原生的配置管理工具，于 2018 年由 Google 开源，并在 2019 年随 kubectl v1.14 正式内置。它采用 “模板免维护” 的设计哲学，通过 叠加层（Overlay） 机制对基础 YAML 进行增量修补，实现环境差异化配置管理。

  核心定义：Kustomize 是一个纯声明式的 Kubernetes 配置定制工具，不依赖模板引擎，通过 kustomization.yaml 文件描述“对基础配置做什么修改”，而非“如何修改”。

Kustomize 的工作流程可概括为：

定义 Base（基础层）：存放通用的、与环境无关的 Kubernetes 资源 YAML。
定义 Overlay（覆盖层）：为每个环境（dev/staging/prod）创建独立的覆盖目录，声明需要修改的字段。
构建输出：Kustomize 自动合并 Base 与 Overlay，生成最终可交付的 YAML。

1.2 Kustomize 与 Helm 的区别

Helm 是 Kubernetes 生态中最流行的包管理器，而 Kustomize 是配置定制工具。两者在 设计哲学、模板机制、依赖管理、学习曲线 等方面存在显著差异。下表从多个维度进行对比：

对比维度	Kustomize	Helm
设计哲学	声明式修补，无模板	模板引擎 + 值注入
模板机制	无模板语言，直接操作 YAML	Go Template + Sprig 函数库
配置输入	kustomization.yaml + 补丁文件	values.yaml + Chart 模板
依赖管理	无内置依赖，通过资源组合实现	内置 Chart 依赖与版本锁定
学习曲线	低，熟悉 YAML 即可上手	中高，需掌握模板语法
调试难度	低，输出即为标准 YAML	中，模板渲染错误较难定位
与 kubectl 集成	原生内置（kubectl -k）	需额外安装 helm CLI
适用场景	环境差异化、GitOps、小规模定制	应用打包分发、复杂依赖、版本管理

选型建议：如果团队追求 简单透明、易于审计、原生集成，Kustomize 是更优选择；如果需要 应用打包、版本回滚、复杂依赖管理，Helm 更合适。实际项目中两者也可互补使用。

1.3 Kustomize 的核心优势

Kustomize 在 Kubernetes 配置管理领域拥有以下不可替代的核心优势：

原生集成，零依赖：自 kubectl v1.14 起内置支持，无需额外安装 CLI 或服务端组件（如 Helm Tiller）。
纯 YAML，无模板：所有配置均为标准 Kubernetes YAML，不引入模板语法，降低学习成本和调试难度。
声明式叠加：通过 Base + Overlay 模式，清晰分离通用配置与环境差异，配置变更可追溯、可审计。
GitOps 友好：输出为纯 YAML，天然适配 Git 版本控制与 CI/CD 流水线，实现“配置即代码”。
补丁灵活：支持 JSON Patch（RFC 6902）和 Strategic Merge Patch 两种补丁策略，可精确修改任意字段。
资源组合与复用：支持跨目录引用、变量替换、名称前缀/后缀、标签/注解注入等高级功能。

注意：Kustomize 并非 Helm 的替代品，而是互补工具。在需要 应用打包分发、版本管理、Chart 仓库 的场景下，Helm 仍然是最佳选择。Kustomize 更适合 环境配置差异化、GitOps 工作流、轻量级定制 的场景。

1.4 典型目录结构示例

一个标准的 Kustomize 项目目录结构如下，清晰体现了 Base 与 Overlay 的分层设计：

my-app/
├── base/                    # 基础层
│   ├── kustomization.yaml   # 基础配置入口
│   ├── deployment.yaml      # 通用 Deployment
│   ├── service.yaml         # 通用 Service
│   └── configmap.yaml       # 通用 ConfigMap
├── overlays/                # 覆盖层
│   ├── dev/                 # 开发环境
│   │   ├── kustomization.yaml
│   │   ├── replica-patch.yaml      # 副本数补丁
│   │   └── configmap-patch.yaml    # 配置补丁
│   ├── staging/             # 预发布环境
│   │   ├── kustomization.yaml
│   │   ├── replica-patch.yaml
│   │   └── ingress-patch.yaml
│   └── prod/                # 生产环境
│       ├── kustomization.yaml
│       ├── replica-patch.yaml
│       ├── resource-patch.yaml     # 资源限制补丁
│       └── hpa-patch.yaml          # HPA 补丁
└── README.md

通过这种结构，团队可以：

共享 Base：所有环境共用同一套基础配置，避免重复维护。
隔离差异：每个环境的差异化配置独立管理，互不干扰。
快速构建：执行 kubectl kustomize overlays/prod 即可生成生产环境完整配置。