type
status
date
slug
summary
category
tags
create_time
Oct 9, 2025 12:20 AM
icon
password
my_create_time

📝 前言

在 Kubernetes 的世界中，配置复用与环境差异管理 一直是部署流程中最具挑战性的部分。
许多人初次接触 Kubernetes 时，往往直接通过kubectl apply -f部署 YAML 文件，但当环境增多（开发 / 测试 / 生产）后，配置管理会迅速变得复杂。
Kustomize 正是为了解决这一痛点而生的，它提供了一种无需模板语法、原生支持 YAML 的配置定制方式。

🧭 背景介绍

在 Helm 诞生之前，大家常用 Shell 或模板语言去动态生成 YAML。
Helm 后来通过 chart 实现了模板化管理，但有些团队并不想引入 Go 模板的复杂性和其带来的学习成本。
Kustomize 以另一种理念出现：
不引入模板语法，而是通过“叠加（Overlay）”和“补丁（Patch）”来管理配置差异。
自 kubectl v1.14+ 起，Kustomize 已被原生集成进 kubectl，成为 Kubernetes 官方推荐的配置管理方式之一。

📋 前提条件

  • 已安装部署 kubernetes 集群
PS：可参看之前文章一键部署：第四部分：使用 sealos 部署集群
  • 已安装 kubectl 工具（默认已内置kustomize）

🚀 详细步骤

1️⃣ 基础概念介绍

概念
说明
Base（基础配置）
公共的、环境无关的 YAML 定义
Overlay（叠加配置）
基于 Base 的环境差异（如 dev / prod）
Patch（补丁）
对资源进行差异化修改
kustomization.yaml
Kustomize 的核心配置文件，用于描述资源、补丁和生成规则

2️⃣ 实战示例

1、目录结构
2、Base 示例
base/deployment.yaml
base/service.yaml
base/kustomization.yaml
3、Dev 环境配置
overlays/dev/patch.yaml
overlays/dev/kustomization.yaml
4、Prod 环境配置
overlays/prod/patch.yaml
overlays/prod/kustomization.yaml

3️⃣ 部署与验证

查看生成的配置（不部署）：
部署对应环境：
最终效果：
  • dev 环境
    • Pod 副本数：1
    • 镜像版本：nginx:1.25-alpine
    • 命名：dev-nginx
    • Label：environment=dev
  • prod 环境
    • Pod 副本数：3
    • 镜像版本：nginx:1.25.5
    • 命名：prod-nginx
    • Label：environment=prod
这里也可以将不同的环境部署的不同的命名空间。

4️⃣ 与 Helm 的区别

特性
Helm
Kustomize
模板语法
使用 Go Template（学习成本高）
无模板，纯 YAML
参数化能力
强大，可定义 values.yaml
简单，基于补丁
打包分发
支持 Chart 仓库
无打包机制，直接 Git 管理
适用场景
复杂多参数部署
轻量环境差异化管理
Kubernetes 支持
独立工具
原生内置于 kubectl

5️⃣ 在 CI/CD 中使用

在 GitOps 场景中（如 Argo CD、Flux CD），Kustomize 被广泛使用：
Kustomize 的纯声明式特性使其非常适合在 GitOps 流程中实现环境分层与可追溯配置。

✅ 总结

Kustomize 提供了一种声明式、无模板、环境可组合的配置管理方式。
它与 Helm 并非竞争关系，而是两种不同的哲学：
  • Helm 强调 打包与复用
  • Kustomize 强调 组合与可维护性
如果你的团队偏向简洁、直接、无模板化的配置管理方式，Kustomize 将是一个极具吸引力的选择。
💡
有关文章的任何疑问，欢迎您在底部评论区留言，一起交流~
 
评论
Loading...
目录