一、什么是 KustomizeKustomize 是Kubernetes 原生的资源配置管理工具用来对 yaml 做补丁、叠加、多环境管理不需要模板语言非 helm原生集成到kubectlkubectl apply -k。定位K8s 原生无模板的配置管理Helm 是包管理器带模板、Chart、values核心思想Base (基础) Overlay (覆盖 / 补丁)不修改原始 yaml通过打补丁生成最终资源命令kubectl apply -k ./-k 代表 kustomize-f 是普通 yaml独立 CLIkustomize build ./输出渲染后的完整 yaml⚠️ 注意kubectl 内置 kustomize 版本往往落后独立 kustomize 二进制版本高级特性建议安装独立 kustomize cli。二、核心概念1. kustomization.yaml入口文件文件名固定必须是 kustomization.yaml/kustomization.yml这是 Kustomize 识别的配置清单。2. base基础层存放公共的原始资源 yaml (deploy/svc/cm)所有环境共用base 本身也可以是一个合法 kustomize 工程自带 kustomization.yaml。base 只定义通用内容不写环境特有的配置。3. overlay覆盖层 / 补丁层基于 base 做修改每个环境一个 overlaydev、test、prod。 overlay 的 kustomization.yaml 引用 base然后添加补丁修改镜像版本修改副本数修改 configmap、env添加 labels/annotations资源补丁 strategicMergePatch /json6902Patch目录结构标准示例k8s/ ├── base/ │ ├── deployment.yaml │ ├── service.yaml │ ├── kustomization.yaml └── overlays/ ├── dev/ │ ├── kustomization.yaml │ └── dev‑patch.yaml └── prod/ ├── kustomization.yaml └── prod‑patch.yamldev/prod 的 kustomization.yaml 中写bases: [../../base]新版推荐用resources:替代 bases 字段✅ 新版本 kustomize 不再推荐bases字段统一使用resources引用基础路径。kustomize.yaml三、kustomization.yaml 常用字段分类 资源引用 resourcesresources: - ./deployment.yaml - ./service.yaml - ../../base # overlay引用base替代旧basesresources导入原始资源可以是本地 yaml 文件也可以是本地 kustomize 目录还支持 git 远程路径。️ 统一标签 注解 commonLabels /commonAnnotations对所有导入的资源统一追加 label/annotation全局生效commonLabels: app: myapp env: dev commonAnnotations: author: dev-teamcommonLabels 是追加不会删除原有 labels。 ConfigMap Secret 生成configMapGenerator /secretGenerator不用手写 cm/secret yamlkustomize 自动生成会自动追加 hash 后缀名字cm 变更 pod 自动滚动更新configMapGenerator: - name: myapp-config files: - config/app.conf literals: - LOG_LEVELINFO secretGenerator: - name: myapp-secret literals: - DB_PASSxxx生成的名字默认带 hash 后缀myapp-config‑789hd7f6bc可以加disableNameSuffixHash: true关闭 hash 后缀。 Patch 补丁两大类最重要补丁不修改 base 源文件在 overlay 打局部修改。patchesStrategicMerge策略合并补丁适合 K8s 原生结构体可以局部合并比如修改副本数、增加环境变量写一个完整局部 yaml 文件。注意StrategicMerge 依赖 K8s 资源的 OpenAPI 结构自定义 CR 支持有限。patchesJSON6902 补丁JSON 补丁标准【新版优先】JSON‑Patch RFC6902json 的增删改操作兼容性最好CRD 资源也可以打补丁支持 inline 内联写补丁不需要外部文件。patches: - target: kind: Deployment name: myapp patch: |- - op: replace path: /spec/replicas value: 3✅ kustomize v4 推荐统一使用patches字段逐步废弃 patchesStrategicMerge。 namespace 设置 namespacenamespace: dev设置后所有资源自动加上 metadata.namespace: dev不需要每个 yaml 写命名空间。四、常用命令# 本地渲染输出最终yaml到stdout kustomize build ./overlays/dev # kubectl内置kustomize直接部署 kubectl apply -k ./overlays/dev #只在本地运行 Kustomize输出最终 YAML kubectl kustomize . # 输出保存文件 kustomize build ./overlays/dev out-dev.yaml # 删除kustomize部署资源 kubectl delete -k ./overlays/dev对比kubectl -k kustomize build kubectl apply五、Kustomize vs Helm 对比项目KustomizeHelm本质配置叠加补丁无模板语法Go 模板语言 Chart 包管理修改方式baseoverlay 打补丁原生 yamlvalues.yaml 渲染模板集成kubectl 原生 (-k)需要 helm 客户端适合场景多环境 yaml 差异化不大轻量管理CI 直接 apply‑k应用分发、复杂模板、公共应用包多值复杂渲染包分发不支持包分发支持 helm repo 仓库分发 Chart选型经验内部自研服务多环境只是镜像、副本数、少量 env 不一样优先 Kustomize需要对外分发应用、大量条件判断 if 模板逻辑优先 Helm 也可以混用Helm 输出 yaml再交给 Kustomize overlay 二次打补丁。六、高频坑点 注意事项❗kustomization.yaml文件名不能写错大小写敏感kubectl 内置 kustomize 版本偏低很多新语法不识别高级功能装独立 kustomize clicommonLabels会加到所有 metadata包括 ConfigMap/Secretgenerator 生成 cm/secret 默认带 hash 后缀好处配置变更 pod 触发滚动更新坏处资源名字每次变patchesStrategicMerge 对 CRD 自定义资源兼容性差优先 RFC6902 patches不要用 varsvars 已弱化废弃尽量用 patch /cm 注入环境变量替代base 本身也可以引用另一个 base支持多层 base 嵌套kustomize 只做本地渲染没有模板 if‑else 逻辑复杂分支逻辑它做不了。七、面试简答版速记Kustomize 是 k8s 原生配置管理工具基于 BaseOverlay不需要模板语言入口文件 kustomization.yaml核心能力统一 labels 注解、镜像替换、自动生成 cm/secret、补丁覆盖、统一 namespace补丁优先 patches (RFC6902)废弃 patchesStrategicMergekubectl apply -k独立命令 kustomize build和 helm 区别kustomize 是配置叠加helm 是模板包管理器轻量多环境选 kustomize。实操部署一个user-service微服务分 dev / prod 两个环境把 Kustomize 从建目录、写配置、预览、校验到部署的整体流程完整走一遍。1. 实例目标我们要部署一个user-service要求环境要求dev1 副本镜像v1.0.0-dev命名空间devprod3 副本镜像v1.0.0命名空间prod整体目录结构如下user-service/ ├── base/ │ ├── kustomization.yaml │ ├── deployment.yaml │ └── service.yaml └── overlays/ ├── dev/ │ └── kustomization.yaml └── prod/ ├── kustomization.yaml └── patch-replicas.yaml2. 第一步创建目录结构mkdir -p user-service/base mkdir -p user-service/overlays/dev mkdir -p user-service/overlays/prod最终目录user-service/ ├── base/ └── overlays/ ├── dev/ └── prod/3. 第二步准备 base 通用配置base/deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: user-service spec: replicas: 1 selector: matchLabels: app: user-service template: metadata: labels: app: user-service spec: containers: - name: user-service image: registry.example.com/user-service:latest ports: - containerPort: 8080base/service.yamlapiVersion: v1 kind: Service metadata: name: user-service spec: selector: app: user-service ports: - port: 80 targetPort: 8080base/kustomization.yamlapiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - deployment.yaml - service.yamlbase只放所有环境都通用的内容不要写死环境差异。4. 第三步准备 dev overlayoverlays/dev/kustomization.yamlapiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - ../../base namespace: dev commonLabels: env: dev images: - name: registry.example.com/user-service newTag: v1.0.0-dev replicas: - name: user-service count: 1这个文件的作用是引入 base 设置命名空间为 dev 加上 envdev 标签 把镜像 Tag 改成 v1.0.0-dev 副本数设置为 15. 第四步准备 prod overlayoverlays/prod/kustomization.yamlapiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization resources: - ../../base namespace: prod commonLabels: env: prod images: - name: registry.example.com/user-service newTag: v1.0.0 replicas: - name: user-service count: 3 patches: - path: patch-replicas.yamloverlays/prod/patch-replicas.yamlapiVersion: apps/v1 kind: Deployment metadata: name: user-service spec: replicas: 3这里用 patch 演示如果某些字段不方便直接用replicas、images修改就可以用 patch 文件做结构化合并。6. 第五步预览 dev 环境kubectl kustomize user-service/overlays/dev或者kustomize build user-service/overlays/dev你应该能看到最终生成的 YAML大致包含namespace: dev labels: env: dev image: registry.example.com/user-service:v1.0.0-dev replicas: 1重点检查命名空间是否正确 镜像 Tag 是否正确 副本数是否正确 Deployment 和 Service 名称是否正确 labels 是否正确7. 第六步预览 prod 环境kubectl kustomize user-service/overlays/prod重点检查namespace 是否为 prod 镜像 Tag 是否为 v1.0.0 副本数是否为 3 patch 是否生效8. 第七步客户端校验预览没问题后先做 dry-run 校验kustomize build user-service/overlays/dev | kubectl apply --dry-runclient -f -kustomize build user-service/overlays/prod | kubectl apply --dry-runclient -f -这一步不会真正创建资源只检查生成的 YAML 是否合法。9. 第八步部署 dev 环境确认无误后部署 devkubectl apply -k user-service/overlays/dev执行后Kustomize 会1. 读取 overlays/dev/kustomization.yaml 2. 引入 base 3. 应用 namespace、labels、images、replicas 4. 生成最终 YAML 5. 提交给 Kubernetes 集群10. 第九步部署 prod 环境部署 prodkubectl apply -k user-service/overlays/prod11. 第十步验证集群状态查看资源kubectl -n dev get deploy,svckubectl -n prod get deploy,svc查看 dev 的 Deploymentkubectl -n dev describe deploy user-service查看 prod 的 Deploymentkubectl -n prod describe deploy user-service重点确认dev 副本数是否为 1 prod 副本数是否为 3 dev 镜像是否为 v1.0.0-dev prod 镜像是否为 v1.0.0 资源是否部署到正确 namespace13. 这个实例体现的 Kustomize 流程base 放通用配置 overlay 放环境差异 kustomization.yaml 负责组合和覆盖 kubectl kustomize 负责预览 kubectl apply -k 负责部署