K8s Kustomize介绍（Kubernetes官方声明式配置管理工具，通过叠加overlay方式定制资源）kubectl内置、Patch补丁机制、GitOps

文章目录

• Kustomize 入门与实践指南：Kubernetes 原生配置管理利器
• • 一、什么是 Kustomize？
  • 二、为什么需要 Kustomize？
  • 三、核心概念
  • • 1. Base（基础配置）
    • 2. Overlay（覆盖层）
    • 3. kustomization.yaml（核心文件）
  • 四、常用功能详解
  • • 1. 资源组合（resources）
    • 2. 修改副本数（replicas）
    • 3. 修改镜像（images）
    • 4. 添加标签（commonLabels）
    • 5. Patch（补丁机制）
    • • Strategic Merge Patch（推荐）
      • JSON Patch（更精细）
    • 6. ConfigMap 和 Secret 生成
  • 五、实际使用方式
  • • 1. 使用 kubectl（推荐）
    • 2. 单独使用 Kustomize
  • 六、典型应用场景
  • • 1. 多环境部署
    • 2. GitOps（如 ArgoCD / Flux）
    • 3. 微服务配置管理
  • 七、Kustomize vs Helm
  • 八、最佳实践
  • • 1. 保持 Base 干净
    • 2. Overlay 只做“差异”
    • 3. 使用 Patch 而不是复制 YAML
    • 4. 结合 Git 管理
  • 九、总结

下面是一篇结构清晰、适合技术博客发布的 Kustomize 介绍文章：

---

Kustomize 入门与实践指南：Kubernetes 原生配置管理利器

在 Kubernetes 日常运维中，我们经常需要面对多环境（dev / staging / prod）、多版本以及差异化配置的问题。如何在保证配置复用的同时，又能灵活定制？这正是Kustomize诞生的背景。

本文将从概念、核心能力、使用方式以及实际场景，系统介绍 Kustomize。

---

一、什么是 Kustomize？

Kustomize 是 Kubernetes 官方提供的声明式配置管理工具，它允许你在不修改原始 YAML 文件的前提下，通过“叠加（overlay）”的方式定制资源。

它的核心理念是：

Base + Overlay = 最终配置

与 Helm 不同，Kustomize 不使用模板引擎，而是直接基于 YAML 进行结构化修改。

---

二、为什么需要 Kustomize？

在实际工作中，你可能遇到这些问题：

• 不同环境配置差异（镜像、资源限制、域名）
• YAML 文件重复、难以维护
• 修改配置容易引入错误
• 不希望引入复杂模板语法（如 Helm）

Kustomize 的优势在于：

• ✅ 无模板（更直观）
• ✅ 原生支持（kubectl 内置）
• ✅ 配置可组合、可复用
• ✅ 易于版本控制（GitOps 友好）

---

三、核心概念

1. Base（基础配置）

Base 是一组通用配置，通常包含：

• Deployment
• Service
• ConfigMap 等

例如：

# base/deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:my-appspec:replicas:2

---

2. 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.yaml

---

2. 修改副本数（replicas）

replicas:-name:my-appcount:5

---

3. 修改镜像（images）

images:-name:my-appnewName:myrepo/my-appnewTag:v2

---

4. 添加标签（commonLabels）

commonLabels:env:dev

---

5. Patch（补丁机制）

Kustomize 支持两种 patch：

Strategic Merge Patch（推荐）

patchesStrategicMerge:-patch.yaml

示例 patch：

apiVersion:apps/v1kind:Deploymentmetadata:name:my-appspec:replicas:10

---

JSON Patch（更精细）

patchesJson6902:-target:kind:Deploymentname:my-apppatch:|--op:replacepath:/spec/replicasvalue:10

---

6. ConfigMap 和 Secret 生成

configMapGenerator:-name:app-configliterals:-ENV=dev

优点：

• 自动生成 hash（避免缓存问题）
• 支持版本变更

---

五、实际使用方式

1. 使用 kubectl（推荐）

kubectl apply-k./overlays/dev

---

2. 单独使用 Kustomize

kustomize build ./overlays/dev

输出最终 YAML。

---

六、典型应用场景

1. 多环境部署

base/ overlays/ ├── dev/ ├── staging/ └── prod/

每个环境只关心差异：

• dev：低资源、测试镜像
• prod：高可用、稳定版本

---

2. GitOps（如 ArgoCD / Flux）

Kustomize 非常适合 GitOps：

• 所有配置存 Git
• Overlay 表达环境差异
• 自动部署

---

3. 微服务配置管理

多个服务共享 Base：

base/ ├── common-labels ├── logging

每个服务只做增量配置。

---

七、Kustomize vs Helm

特性	Kustomize	Helm
模板引擎	❌ 无	✅ 有
学习成本	低	中
灵活性	中	高
可读性	高	一般
官方支持	✅ kubectl 内置	❌ 需单独安装

👉 简单总结：

• 想要简单 + 原生 + 可读性高→ 用 Kustomize
• 想要复杂逻辑 + 高度动态配置→ 用 Helm

---

八、最佳实践

1. 保持 Base 干净

• 不要写环境相关配置
• 只保留通用逻辑

---

2. Overlay 只做“差异”

避免复制 Base 内容。

---

3. 使用 Patch 而不是复制 YAML

减少重复，提高可维护性。

---

4. 结合 Git 管理

• 每个环境一个目录
• PR 审核配置变更

---

九、总结

Kustomize 是 Kubernetes 原生、轻量但强大的配置管理工具，它通过“叠加”的方式优雅地解决了多环境配置问题。

它的核心价值在于：

• 去模板化（更简单）
• 结构化修改（更安全）
• 天然适配 GitOps（更现代）

如果你已经在使用 Kubernetes，Kustomize 是一个非常值得掌握的工具。