18-Kustomize 配置管理

Kustomize 配置管理概念引入文章 17 学了 Helm——用模板 values 管理配置。但 Helm 有一个特点你的 YAML 里全是{{ .Values.xxx }}不渲染出来就看不懂。Kustomize 走了另一条路——不写模板只写补丁。Base 是完整的工作配置overlay 只写和 base 不同的地方Helm 方式 Kustomize 方式 ───────── ───────────── base: 有 code v-pre{{ 占位符 }}/code 的模板 base: 完整可用的 YAML env: values.yaml 填入值 env: 只写差异patch 你看模板时 → 这到底渲染出来是啥 你看 base 时 → ✅ 这就是 staging 的完整配置可以直接 kubectl applyOverlay: Stagingkustomization.yamlpatches replicas: 2image: myapp:1.0-rcOverlay: Productionkustomization.yamlpatches replicas: 5image: myapp:1.0-prodBase基础配置deployment.yamlimage: myapp:1.0replicas: 2service.yamlport: 80学完本篇你将能够用 base overlay 目录结构管理多环境dev/staging/prod配置编写 kustomization.yaml通过 patches 覆盖副本数、镜像标签等差异用kubectl apply -k一键部署无需额外模板引擎原理讲解目录结构├── base/ │ ├── deployment.yaml # 通用 Deployment │ ├── service.yaml # 通用 Service │ └── kustomization.yaml # 列出 base 包含哪些资源 │ └── overlays/ ├── staging/ │ ├── kustomization.yaml # 引用 base 补丁 │ └── replica-count.yaml # 只改副本数 │ └── production/ ├── kustomization.yaml ├── replica-count.yaml └── image-tag.yamlkustomization.yaml 核心字段base/kustomization.yamlapiVersion:kustomize.config.k8s.io/v1beta1kind:Kustomizationresources:-deployment.yaml-service.yamloverlays/production/kustomization.yamlapiVersion:kustomize.config.k8s.io/v1beta1kind:Kustomization# 引用 baseresources:-../../base# 打标签commonLabels:env:production# 改镜像images:-name:myappnewTag:1.0-prod# 改副本数通过 patchpatches:-path:replica-count.yamloverlays/production/replica-count.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:myappspec:replicas:5常用功能功能写法效果改镜像images:修改 Deployment 的 image tag打标签commonLabels:给所有资源统一加 label加注解commonAnnotations:给所有资源统一加 annotation补丁patches:只修改特定字段JSON Patch 或 Strategic Merge生成 ConfigMapconfigMapGenerator:从文件自动生成 ConfigMap带 content hash触发滚动更新生成 SecretsecretGenerator:从文件/字面量自动生成 Secret名前缀namePrefix:加前缀区分环境ConfigMap Generator 的杀手特性# overlays/production/kustomization.yamlconfigMapGenerator:-name:app-configfiles:-config.properties# 从文件读取内容behavior:merge# 合并到 base 已有的 ConfigMap自动 hash每次 config.properties 内容变化Kustomize 会自动生成不同的 ConfigMap 名称如app-config-7km8f29h4dDeployment 引用这个新名字 → 触发 Pod 滚动更新。改了配置就自动更新不需要手动重启。Kustomize vs Helm 选型✅ 是❌ 差异大✅ 是❌ 自己用✅ 是需要更复杂逻辑你需要什么YAML 差异小环境间只是副本数/镜像不同Kustomizebase overlay简单直观需要分发/共享团队间或社区共享 ChartHelmChart values 模板化生态好Chart 仓库多用 kubectl 就够了Kustomizekubectl 原生集成kubectl apply -k ./overlays/prodHelm条件/循环/函数特性HelmKustomize学习曲线中等Go template 语法低就是 YAML原生集成helm installkubectl apply -k模板能力✅ 条件/循环/函数❌ 无模板只改字段社区生态✅ 大量第三方 Chart❌ 无中央仓库可读性模板不直观✅ 随时可读多环境values 文件切换overlay 目录动手实验配套实验位于docs/labs/beginner/kustomize/步骤 1部署实验环境cddocs/labs/beginner/kustomizebashsetup.sh步骤 2查看 base 和 overlay 的结构# 查看目录结构ls-Rbase/ overlays/# 预览渲染结果kustomize build 输出完整 YAMLkubectl kustomize base/ kubectl kustomize overlays/staging/ kubectl kustomize overlays/production/步骤 3部署 staging 和 production 到不同 Namespace# 部署到 staging namespacekubectl apply-koverlays/staging/# 部署到 production namespacekubectl apply-koverlays/production/# 对比两个环境的差异kubectl get deploy-nstaging-owide kubectl get deploy-nproduction-owide# 预期production 副本数更多步骤 4验证 ConfigMap Generator 的自动 hash# 查看生成的 ConfigMap 名称kubectl get configmap-nproduction# 输出类似 app-config-7km8f29h4d带 hash# Deployment 自动引用了带 hash 的名字kubectl get deploy-nproduction-ojson|jq-r.items[0].spec.template.spec.volumes[] | select(.nameconfig) | .configMap.name步骤 5清理bashteardown.sh自检问题[基础]Helm 用{{ .Values.replicas }}模板Kustomize 用什么方式处理环境差异[理解]Kustomize 的 ConfigMap Generator 会给 ConfigMap 名字加 hash这解决了什么问题[应用]你的团队目前用 Helm 管理 3 个环境dev/staging/prod但每次看模板都很难直观理解。改成 Kustomize 后目录结构怎么设计查看答案Kustomize 用patch补丁方式。Base 目录是一份完整的、可以直接部署的 YAML。每个 overlay 只需要写 kustomization.yaml 少量补丁文件描述和 base 的差异改镜像 tag、改副本数、加 label 等。不写模板不写占位符。解决了ConfigMap 更新后 Pod 不重启的经典问题。ConfigMap 内容变了Kustomize 生成新的 hash → ConfigMap 名字变了 → Deployment 的引用变了 → 触发 Pod 滚动更新。之前你需要手动改 Deployment 的 annotation 或重启 Pod现在自动完成。app/ ├── base/ │ ├── deployment.yaml │ ├── service.yaml │ └── kustomization.yaml │ ├── overlays/ │ ├── dev/ │ │ ├── kustomization.yaml # replicas: 1, image: dev │ │ └── debug-sidecar.yaml # 仅 dev 加 debug 容器 │ │ │ ├── staging/ │ │ ├── kustomization.yaml # replicas: 2, image: rc │ │ └── ingress.yaml # staging 专用域名 │ │ │ └── production/ │ ├── kustomization.yaml # replicas: 5, image: prod │ ├── resource-limits.yaml # 生产资源配置 │ └── pdb.yaml # 生产可用性保障部署kubectl apply -k overlays/production/下一步配置管理有两条路可选了。接下来学习怎么运维 K8s 集群本身→ 29. 集群升级与维护 本文来自 K8s Guide —— 开源免费的 Kubernetes 中文学习指南️ 初学者轨道 面试轨道从零基础到拿 Offer 一站式覆盖 每篇文章配套 Kind 实验脚本本地一键运行 本文源码docs/beginner/20-gateway-api.md⭐ 如果对你有帮助欢迎 Star github.com/callmebg/k8s-guide