Kustomize 入门

你有没有遇到过这种情况：开发、测试、生产三套环境，YAML 几乎一模一样，只有镜像标签、副本数、命名空间不同。于是你复制粘贴三份，改几个值，结果哪天改了一处忘了同步，线上就出了事故。

Kustomize 就是来解决这个问题的。它不引入新的模板语言，而是直接基于 Kubernetes 原生的 YAML 做”叠加定制”。你可以把基础配置写一份，再用一个小文件描述”这个环境要改哪些地方”，它就帮你生成最终配置。

53-1 Kustomize 是什么

Kustomize 是一个定制 Kubernetes 配置的工具。它从 1.14 版本起被 kubectl 原生支持，所以你通常不需要单独安装它。

它的核心思想很朴素：配置就是一堆 Kubernetes 资源，定制就是给这批资源统一加前缀、打补丁、换镜像。整个过程不需要写 if/else 之类的模板逻辑，所见即所得。

你可以把 Kustomize 理解为一个”配置加工流水线”。输入端是基础 YAML，加工端是 kustomization.yaml 里的指令，输出端是能直接 kubectl apply 的完整清单。

53-2 用 kubectl 查看与应用

只要一个目录里有 kustomization.yaml 文件，kubectl 就能识别它。先看看会生成什么：

kubectl kustomize ./my-app/

应用这些资源，用 -k 参数代替 -f：

kubectl apply -k ./my-app/

查看、比较、删除也同样支持：

kubectl get -k ./my-app/
kubectl diff -k ./my-app/
kubectl delete -k ./my-app/

53-3 生成 ConfigMap 与 Secret

很多配置来自集群外部，比如一个 .properties 文件或 SSH 密钥。Kustomize 提供 configMapGenerator 和 secretGenerator，能从文件或字面值直接生成资源。

从文件生成 ConfigMap：

# kustomization.yaml
configMapGenerator:
- name: example-config
  files:
  - application.properties

从字面值生成 Secret：

# kustomization.yaml
secretGenerator:
- name: example-secret
  literals:
  - username=admin
  - password=change-me  # 示例值，实际替换成你的密码

生成的名字后面会带一个内容哈希后缀，比如 example-config-8mbdf7882g。好处很明显：内容一变，名字就变，Kubernetes 会创建新资源而非原地修改，滚动更新更可靠。

如果你不想要这个后缀，可以用 generatorOptions 关闭：

generatorOptions:
  disableNameSuffixHash: true
  labels:
    type: generated

53-4 设置贯穿性字段

“贯穿性字段”指的是对所有资源统一生效的配置。比如给所有资源加同一个命名空间、统一前缀、统一标签。

# kustomization.yaml
namespace: my-namespace
namePrefix: dev-
nameSuffix: "-001"
commonAnnotations:
  oncallPager: 800-555-1212
labels:
  - pairs:
      app: bingo
    includeSelectors: true
resources:
- deployment.yaml

加工后，Deployment 的名字会变成 dev-nginx-deployment-001，并且它的 selector 里的标签也会同步更新。这点很关键：手动改名字容易漏掉选择器，Kustomize 帮你一并处理。

53-5 用补丁定制资源

补丁（patches）用来在基础配置上做局部修改。比如把副本数从 2 改到 3，单独写一个补丁文件最清晰：

# increase_replicas.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  replicas: 3

# kustomization.yaml
resources:
- deployment.yaml
patches:
  - path: increase_replicas.yaml

补丁通过 group、version、kind、name 来锁定目标资源。Kustomize 支持两种补丁机制：StrategicMerge（策略合并，最常用）和 Json6902（精确 JSON 路径修改，适合任意字段）。

想换镜像也很简单，连补丁文件都不用写：

images:
- name: nginx
  newName: my.image.registry/nginx
  newTag: "1.4.0"

53-6 bases 与 overlays

当配置要复用到多个环境时，Kustomize 用”基准（base）“和”覆盖（overlay）“来组织。

base 是一份通用配置，本身不知道自己会被谁使用：

# base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml

overlay 引用 base，再叠加本环境特有的定制：

# dev/kustomization.yaml
resources:
- ../base
namePrefix: dev-

# prod/kustomization.yaml
resources:
- ../base
namePrefix: prod-

这样开发和生产共用同一份 base，只在 overlay 里写差异。改了 base，两个环境同时受益。

53-7 该在哪里用 Kustomize

如果你的配置只是”同一套东西，多环境微调”，Kustomize 非常顺手。它和 GitOps 工具（比如 Argo CD）配合默契，Argo CD 原生就认 kustomization.yaml。

但如果配置差异大到需要条件判断、循环生成，那 Helm 的模板能力会更强。两者不是死对头，很多团队用 Helm 管应用、用 Kustomize 管环境差异。

一句话记住：Kustomize 让你”不改原文件，只描述变化”，这正是它清爽的地方。