文章目录Kustomize 入门与实践指南Kubernetes 原生配置管理利器一、什么是 Kustomize二、为什么需要 Kustomize三、核心概念1. Base基础配置2. Overlay覆盖层3. kustomization.yaml核心文件四、常用功能详解1. 资源组合resources2. 修改副本数replicas3. 修改镜像images4. 添加标签commonLabels5. Patch补丁机制Strategic Merge Patch推荐JSON Patch更精细6. ConfigMap 和 Secret 生成五、实际使用方式1. 使用 kubectl推荐2. 单独使用 Kustomize六、典型应用场景1. 多环境部署2. GitOps如 ArgoCD / Flux3. 微服务配置管理七、Kustomize vs Helm八、最佳实践1. 保持 Base 干净2. Overlay 只做“差异”3. 使用 Patch 而不是复制 YAML4. 结合 Git 管理九、总结下面是一篇结构清晰、适合技术博客发布的 Kustomize 介绍文章Kustomize 入门与实践指南Kubernetes 原生配置管理利器在 Kubernetes 日常运维中我们经常需要面对多环境dev / staging / prod、多版本以及差异化配置的问题。如何在保证配置复用的同时又能灵活定制这正是Kustomize诞生的背景。本文将从概念、核心能力、使用方式以及实际场景系统介绍 Kustomize。一、什么是 KustomizeKustomize 是 Kubernetes 官方提供的声明式配置管理工具它允许你在不修改原始 YAML 文件的前提下通过“叠加overlay”的方式定制资源。它的核心理念是Base Overlay 最终配置与 Helm 不同Kustomize 不使用模板引擎而是直接基于 YAML 进行结构化修改。二、为什么需要 Kustomize在实际工作中你可能遇到这些问题不同环境配置差异镜像、资源限制、域名YAML 文件重复、难以维护修改配置容易引入错误不希望引入复杂模板语法如 HelmKustomize 的优势在于✅ 无模板更直观✅ 原生支持kubectl 内置✅ 配置可组合、可复用✅ 易于版本控制GitOps 友好三、核心概念1. Base基础配置Base 是一组通用配置通常包含DeploymentServiceConfigMap 等例如# base/deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:my-appspec:replicas:22. Overlay覆盖层Overlay 用于在 Base 的基础上做定制例如修改副本数替换镜像添加标签目录结构示例kustomize/ ├── base/ │ ├── deployment.yaml │ └── kustomization.yaml ├── overlays/ │ ├── dev/ │ └── prod/3. kustomization.yaml核心文件这是 Kustomize 的入口文件用于声明资源和修改规则。示例resources:-../../basereplicas:-name:my-appcount:3images:-name:my-appnewTag:v2四、常用功能详解1. 资源组合resources将多个 YAML 组合在一起resources:-deployment.yaml-service.yaml2. 修改副本数replicasreplicas:-name:my-appcount:53. 修改镜像imagesimages:-name:my-appnewName:myrepo/my-appnewTag:v24. 添加标签commonLabelscommonLabels:env:dev5. Patch补丁机制Kustomize 支持两种 patchStrategic Merge Patch推荐patchesStrategicMerge:-patch.yaml示例 patchapiVersion:apps/v1kind:Deploymentmetadata:name:my-appspec:replicas:10JSON Patch更精细patchesJson6902:-target:kind:Deploymentname:my-apppatch:|--op:replacepath:/spec/replicasvalue:106. ConfigMap 和 Secret 生成configMapGenerator:-name:app-configliterals:-ENVdev优点自动生成 hash避免缓存问题支持版本变更五、实际使用方式1. 使用 kubectl推荐kubectl apply-k./overlays/dev2. 单独使用 Kustomizekustomize build ./overlays/dev输出最终 YAML。六、典型应用场景1. 多环境部署base/ overlays/ ├── dev/ ├── staging/ └── prod/每个环境只关心差异dev低资源、测试镜像prod高可用、稳定版本2. GitOps如 ArgoCD / FluxKustomize 非常适合 GitOps所有配置存 GitOverlay 表达环境差异自动部署3. 微服务配置管理多个服务共享 Basebase/ ├── common-labels ├── logging每个服务只做增量配置。七、Kustomize vs Helm特性KustomizeHelm模板引擎❌ 无✅ 有学习成本低中灵活性中高可读性高一般官方支持✅ kubectl 内置❌ 需单独安装 简单总结想要简单 原生 可读性高→ 用 Kustomize想要复杂逻辑 高度动态配置→ 用 Helm八、最佳实践1. 保持 Base 干净不要写环境相关配置只保留通用逻辑2. Overlay 只做“差异”避免复制 Base 内容。3. 使用 Patch 而不是复制 YAML减少重复提高可维护性。4. 结合 Git 管理每个环境一个目录PR 审核配置变更九、总结Kustomize 是 Kubernetes 原生、轻量但强大的配置管理工具它通过“叠加”的方式优雅地解决了多环境配置问题。它的核心价值在于去模板化更简单结构化修改更安全天然适配 GitOps更现代如果你已经在使用 KubernetesKustomize 是一个非常值得掌握的工具。