
KustomizeKubernetes 配置管理无模板覆盖定制 YAMLKubernetes 应用的配置管理是 DevOps 实践中的核心挑战同一套应用需要在开发、测试、生产等多个环境部署各环境的镜像版本、副本数量、资源配额都不相同。Helm 是常见解决方案但其模板语言学习曲线陡峭YAML 中嵌入大量{{ }}语法可读性较差。Kustomize 提供了另一种思路无模板覆盖。它保持原始 YAML 的完整可读性通过 overlay覆盖层机制按环境叠加差异配置已内置于kubectl无需额外安装。服务器配置Kustomize 对服务器资源要求不高任何安装了 kubectl 的环境都可以使用。可考虑使用雨云服务器 rainyun-com2 核 4GB 机型运行 K3s注册填码2026off领 5 折即可获得一台性能充裕的 Kubernetes 开发与学习环境。本文环境操作系统Ubuntu 22.04 LTSkubectlv1.28K3sv1.28可选Kustomize 核心概念Kustomize 的核心是base overlays目录结构base/通用的 K8s 资源定义不含任何环境差异overlays/dev/开发环境专用的差异配置overlays/prod/生产环境专用的差异配置更多副本、不同镜像标签kustomization.yaml每个目录的清单文件声明包含哪些资源、应用哪些补丁Kustomize 使用方式# kubectl 内置推荐kubectl apply-k./overlays/prod# 独立二进制输出到 stdoutkustomize build ./overlays/prod|kubectl apply-f-# 预览差异不实际应用kubectldiff-k./overlays/prod第一步创建项目目录结构mkdir-pmy-app/{base,overlays/dev,overlays/prod}最终目录结构如下my-app/ ├── base/ │ ├── kustomization.yaml │ ├── deployment.yaml │ ├── service.yaml │ └── configmap.yaml ├── overlays/ │ ├── dev/ │ │ ├── kustomization.yaml │ │ └── patch-replicas.yaml │ └── prod/ │ ├── kustomization.yaml │ ├── patch-replicas.yaml │ └── patch-resources.yaml第二步创建 base 基础配置base/deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:my-applabels:app:my-appspec:replicas:1selector:matchLabels:app:my-apptemplate:metadata:labels:app:my-appspec:containers:-name:my-appimage:my-app:latestports:-containerPort:8080resources:requests:cpu:100mmemory:128Milimits:cpu:200mmemory:256Mibase/service.yamlapiVersion:v1kind:Servicemetadata:name:my-appspec:selector:app:my-appports:-port:80targetPort:8080base/configmap.yamlapiVersion:v1kind:ConfigMapmetadata:name:my-app-configdata:LOG_LEVEL:infoMAX_CONNECTIONS:100base/kustomization.yamlapiVersion:kustomize.config.k8s.io/v1beta1kind:Kustomizationresources:-deployment.yaml-service.yaml-configmap.yaml第三步创建 dev 覆盖层overlays/dev/patch-replicas.yaml使用Strategic Merge Patch策略合并补丁只需写出需要改变的字段apiVersion:apps/v1kind:Deploymentmetadata:name:my-appspec:replicas:1overlays/dev/kustomization.yamlapiVersion:kustomize.config.k8s.io/v1beta1kind:Kustomization# 引用上级 basebases:-../../base# 命名空间覆盖namespace:dev# 名称前缀避免与 prod 冲突namePrefix:dev-# 公共标签commonLabels:environment:dev# 镜像标签覆盖images:-name:my-appnewTag:dev-latest# 应用补丁patches:-path:patch-replicas.yaml第四步创建 prod 覆盖层overlays/prod/patch-replicas.yaml生产环境需要 3 个副本apiVersion:apps/v1kind:Deploymentmetadata:name:my-appspec:replicas:3overlays/prod/patch-resources.yaml使用JSON 6902 Patch精确修改资源限制适合深层路径的精确操作-op:replacepath:/spec/template/spec/containers/0/resources/limits/cpuvalue:1000m-op:replacepath:/spec/template/spec/containers/0/resources/limits/memoryvalue:512Mi-op:replacepath:/spec/template/spec/containers/0/resources/requests/cpuvalue:500m-op:replacepath:/spec/template/spec/containers/0/resources/requests/memoryvalue:256Mioverlays/prod/kustomization.yamlapiVersion:kustomize.config.k8s.io/v1beta1kind:Kustomizationbases:-../../basenamespace:productioncommonLabels:environment:productioncommonAnnotations:managed-by:kustomizeteam:platformimages:-name:my-appnewTag:v1.2.3patches:-path:patch-replicas.yaml-path:patch-resources.yamltarget:kind:Deploymentname:my-app第五步ConfigMap 和 Secret 生成器Kustomize 的configMapGenerator可以从文件或环境变量自动生成 ConfigMap并在名称后附加内容哈希值实现配置变更时触发 Deployment 滚动更新# 在 kustomization.yaml 中添加configMapGenerator:-name:my-app-configliterals:-LOG_LEVELinfo-MAX_CONNECTIONS200# 或从文件加载# files:# - configs/app.propertiessecretGenerator:-name:my-app-secretsliterals:-DB_PASSWORDsupersecret-API_KEYmyapikeytype:Opaque生成的 ConfigMap 名称会变为my-app-config-hash当内容变化时哈希改变关联的 Deployment 会自动触发滚动更新。第六步Transformers 变换器除了补丁Kustomize 还支持全局变换器# kustomization.yamlnamePrefix:prod-# 所有资源名称加前缀nameSuffix:-v2# 所有资源名称加后缀namespace:production# 统一设置命名空间commonLabels:# 为所有资源添加标签app.kubernetes.io/managed-by:kustomizeapp.kubernetes.io/version:1.2.3commonAnnotations:# 为所有资源添加注解git-commit:abc1234第七步images 字段在 CI/CD 中的应用images字段是 CI/CD 流水线中最常用的 Kustomize 特性构建新镜像后只需更新镜像标签images:-name:my-appnewName:registry.example.com/my-app# 替换镜像仓库地址newTag:20260517-abc1234# 替换为 CI 构建的标签在 CI 流水线GitHub Actions / Jenkins中使用kustomize edit set image命令动态修改标签# CI 脚本中IMAGE_TAG${GIT_COMMIT::8}# 进入 overlay 目录并更新镜像标签cdoverlays/prod kustomize editsetimage my-appregistry.example.com/my-app:${IMAGE_TAG}# 提交变更到 GitOps 仓库gitaddkustomization.yamlgitcommit-mchore: update image to${IMAGE_TAG}gitpush第八步与 ArgoCD 集成ArgoCD 原生支持 Kustomize只需在 Application 资源中指定路径apiVersion:argoproj.io/v1alpha1kind:Applicationmetadata:name:my-app-prodnamespace:argocdspec:project:defaultsource:repoURL:https://github.com/myorg/my-app-configtargetRevision:HEADpath:overlays/proddestination:server:https://kubernetes.default.svcnamespace:productionsyncPolicy:automated:prune:trueselfHeal:trueArgoCD 会自动执行kustomize build overlays/prod并将输出与集群实际状态对比检测到差异时触发同步。部署前预览kubectl diff在实际应用前务必使用kubectl diff预览变更内容kubectldiff-k./overlays/prod输出类似git diff-表示删除表示新增方便在 Code Review 阶段发现意外变更。Strategic Merge Patch vs JSON 6902 Patch 对比特性Strategic Merge PatchJSON 6902 Patch语法部分 YAMLJSON Patch 操作可读性高中精确性中按字段合并高精确路径操作适用场景修改顶层字段修改嵌套深层字段支持列表操作有限完整add/remove/replaceKustomize 以无模板理念解决了多环境配置管理的痛点通过 base overlays 的分层结构在保持 YAML 可读性的同时实现环境差异的精确控制。结合 ArgoCD 的 GitOps 工作流每次代码合并都能自动触发集群同步是云原生团队配置管理的最佳实践之一。