第四部分：Kustomize 快速入门

📝 前言

在 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、目录结构

1
2
3
4
5
6
7
8
9
10
11
12
kustomize-demo/
├── base/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── kustomization.yaml
└── overlays/
    ├── dev/
    │   ├── kustomization.yaml
    │   └── patch.yaml
    └── prod/
        ├── kustomization.yaml
        └── patch.yaml

2、Base 示例

base/deployment.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

base/service.yaml

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

base/kustomization.yaml

1
2
3
resources:
  - deployment.yaml
  - service.yaml

3、Dev 环境配置

overlays/dev/patch.yaml

1
2
3
4
5
6
7
8
9
10
11
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25-alpine

overlays/dev/kustomization.yaml

1
2
3
4
5
6
7
8
9
10
resources:
  - ../../base

patches:
  - path: patch.yaml
# 资源名称自动带上dev-前缀
namePrefix: dev-
# 自动添加标签
commonLabels:
  environment: dev

4、Prod 环境配置

overlays/prod/patch.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.5
        env:
          - name: NGINX_LOG_LEVEL
            value: "warn"

overlays/prod/kustomization.yaml

1
2
3
4
5
6
7
8
9
10
11
resources:
  - ../../base

patches:
  - path: patch.yaml

namePrefix: prod-
commonLabels:
  environment: prod
# 生产环境部署到其他命名空间
# namespace: production

3️⃣ 部署与验证

查看生成的配置（不部署）：

1
2
kubectl kustomize overlays/dev
kubectl kustomize overlays/prod

部署对应环境：

1
2
kubectl apply -k overlays/dev
kubectl apply -k overlays/prod

最终效果：

  • 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 被广泛使用：

1
kubectl apply -k ./overlays/prod

Kustomize 的纯声明式特性使其非常适合在 GitOps 流程中实现环境分层与可追溯配置。

✅ 总结

Kustomize 提供了一种声明式、无模板、环境可组合的配置管理方式。

它与 Helm 并非竞争关系，而是两种不同的哲学：

  • Helm 强调 打包与复用
  • Kustomize 强调 组合与可维护性

如果你的团队偏向简洁、直接、无模板化的配置管理方式，Kustomize 将是一个极具吸引力的选择。