LJTian Blog
LJTian Blog/
🛻
云原生/
🧣
Kubernetes Kustomize 介绍
Search
Kubernetes Kustomize 介绍
🧣

Kubernetes Kustomize 介绍

介绍

notion image

通俗描述

如图所示，这个东西只是借鉴了类似 OverlayFS 的分层思想。也是通过分层方式叠加覆盖的方式进行修改。主要通过配置文件来对当前层的文件进行对应修改后，然后通 overlayFS 高层覆盖底层进行文件整合目录生成最终层进行展示应用。
 

详细解析 kustomize.yaml 文件

notion image
可以看到在各个层中都有一个 kustomize.yaml 文件，这个文件就是 kustomize 的配置文件。

先看一下 base 下的 kustomize.yaml 文件内容

╰─$ cat base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml
非常简单就是关联了一下对应的资源

在看一下 overlays 下的 kustomize.yaml 文件内容

╰─$ cat overlays/prod/kustomization.yaml
resources:
- ../../base   # 引用 Base 层

# 【功能 1: 统一前缀】
# 所有生成的资源（Service, Deployment, ConfigMap）名字都会加上 "prod-"
namePrefix: prod-

# 【功能 2: 统一标签】
# 所有资源都会被打上 "env: production" 标签
commonLabels:
  env: production

# 【功能 3: 镜像替换】
# 强行将 base 里的 nginx:1.14.2 替换为最新版 1.21
images:
- name: docker-0.unsee.tech/docker.io/library/nginx
  newTag: '1.21'

# 【功能 4: ConfigMap Generator (杀手锏)】
# 读取文件生成 ConfigMap，并自动添加 Hash 后缀
configMapGenerator:
- name: site-config
  files:
  - config/index.html

# 【功能 5: 应用补丁】
patches:
- path: patch-deployment.yaml
需要注意一下，prod 目录下和 test 目录下的 kustomize.yaml 配置文件都是修改配置描述，只是不同的环境使用不同的修改层的区别。
这个配置文件主要用来描述我们要修改基础层的那些内容，例如 修改名字格式 namePrefix、批量添加标签 commonLabels、镜像替换 images 等。

它解决的主要问题是：

  • 拒绝“复制粘贴”： 以前为了区分开发和生产环境，我们得把 1000 行的 YAML 文件复制两份，哪怕其中 990 行都是一样的。现在，那 990 行通用的代码只需要维护一份。
  • 修改一处，处处生效： 如果你想升级镜像版本，只需要改“基础款”，所有环境（开发、测试、生产）都会自动用上新镜像，不会漏改。
  • 安全可追溯： 所有的修改都是以“补丁文件”的形式存在的，非常适合上传到 Git 仓库。谁在什么时候改了副本数、改了内存限制，清清楚楚。

演示

1. 教程目标

本教程将带您从零构建一个符合行业标准的 Kustomize 项目。我们将通过部署一个 Nginx 应用，一次性演练 Kustomize 的六大核心功能：
  1. Base/Overlay 架构：多环境复用（测试环境与生产环境共用一些基础配置）。
  1. namePrefix：资源命名空间隔离（资源名称格式化）。
  1. commonLabels：全资源统一标签（添加统一 label 方便管理）。
  1. images：镜像版本统一替换（批量替换镜像）。
  1. Patches：属性修改与容器挂载点注入。
  1. ConfigMap Generator：配置变更触发 Pod 自动重启（杀手锏）。

2. 准备工作：目录结构

首先，我们建立一个标准的 Kustomize 目录结构。
打开终端，执行以下命令：
# 创建项目根目录
mkdir -p kustomize-demo/base
mkdir -p kustomize-demo/overlays/prod
mkdir -p kustomize-demo/overlays/prod/config

# 进入项目目录
cd kustomize-demo

3. 第一阶段：编写 Base 层（地基）

Base 层存放通用的、所有环境都一样的配置。这里我们定义一个最基础的 Nginx，没有任何特殊挂载或副本设置。

3.1 创建 Deployment

文件路径：base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
	      # 这是一个旧版本，稍后我们会在 Prod 环境替换它
        image: m.daocloud.io/docker.io/library/nginx:1.14.2  
        ports:
        - containerPort: 80

3.2 创建 Service

文件路径：base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-nginx
spec:
  selector:
    app: my-nginx
  ports:
  - port: 80
    targetPort: 80

3.3 创建 Base 索引文件

文件路径：base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml

4. 第二阶段：编写 Overlay 层（生产环境特效）

Overlay 层定义环境特有的差异。我们将在这里集中展示 Kustomize 的所有黑科技。

4.1 准备配置文件素材

文件路径：overlays/prod/config/index.html
<h1>Hello from Production! v1</h1>

4.2 编写补丁 (Patch)

我们需要修改 Base 中的 Deployment。这里演示了修改字段（改副本数）和注入新结构（挂载 Volume）两种操作。
文件路径：overlays/prod/patch-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx  # 必须与 Base 名称一致，Kustomize 才能定位
spec:
  replicas: 3     # 【修改】将副本数从默认值改为 3
  template:
    spec:
      containers:
      - name: nginx
        volumeMounts: # 【注入】Base 里没有挂载，我们在补丁里强行加上
        - name: html-volume
          mountPath: /usr/share/nginx/html
      volumes:    # 【注入】定义 Volume，引用下方生成的 ConfigMap
      - name: html-volume
        configMap:
          name: site-config

4.3 编写 Prod 核心配置 (关键)

这是本教程最重要的文件，它组装了所有功能。
文件路径：overlays/prod/kustomization.yaml
resources:
- ../../base   # 引用 Base 层

# 【功能 1: 统一前缀】
# 所有生成的资源（Service, Deployment, ConfigMap）名字都会加上 "prod-"
namePrefix: prod-

# 【功能 2: 统一标签】
# 所有资源都会被打上 "env: production" 标签
commonLabels:
  env: production

# 【功能 3: 镜像替换】
# 强行将 base 里的 nginx:1.14.2 替换为最新版 1.21
images:
- name: m.daocloud.io/docker.io/library/nginx
  newTag: '1.21'

# 【功能 4: ConfigMap Generator (杀手锏)】
# 读取文件生成 ConfigMap，并自动添加 Hash 后缀
configMapGenerator:
- name: site-config
  files:
  - config/index.html

# 【功能 5: 应用补丁】
patches:
- path: patch-deployment.yaml

5. 第三阶段：构建与校验

5.1 执行构建

在 kustomize-demo 根目录下运行：
kubectl kustomize overlays/prod

5.2 结果解读(这个内容在展示最终的 yaml 信息，并没有执行)

请观察终端输出的 YAML，您会看到以下变化：
  1. 名称变化：Deployment 名字变成了 prod-my-nginx（前缀生效）。
  1. 标签变化：所有资源都多了 env: production（标签生效）。
  1. 镜像变化：image 变成了 nginx:1.21（镜像替换生效）。
  1. 结构变化：Deployment 里多了 replicas: 3 和 volumeMounts（补丁生效）。
  1. Hash 魔法：ConfigMap 名字变成了类似 prod-site-config-ck7bg9k276，且 Deployment 里的引用也自动变成了这个带 Hash 的名字。

应用验证

验证“自动重启”机制，这是 Kustomize 相比 Helm 最强大的特性之一。

1. 执行 kubectl apply -k

kubectl apply -k overlays/prod

2. 设置端口转发

kubectl port-forward service/prod-my-nginx 8080:80

3. 通过浏览器查看结果

notion image

4. 修改配置

修改 overlays/prod/config/index.html 的内容：
<h1>Hello from Production! v2 (Updated)</h1>

5. 再次构建并设置转发

再次运行 kubectl kustomize overlays/prod。
kubectl apply -k overlays/prod && kubectl port-forward service/prod-my-nginx 8080:80

6.观察差异

notion image
你会发现：
  • ConfigMap 的名字后缀变了（例如从 ck7... 变为 f7m...）。
  • Deployment spec.template.spec.volumes 中引用的 ConfigMap 名字也随之改变。

7. 结论

当您将这个新的 YAML 应用到集群 (kubectl apply) 时，Kubernetes 会检测到 Deployment 的定义发生了变化（因为引用的 ConfigMap 名字变了），从而立即触发 Pod 的滚动更新 (Rolling Update)。
这意味着：您只需修改配置文件，无需手动重启 Pod，新配置即可上线。

结尾

github 地址：https://github.com/LJTian/k8s-test

 
Copyright 2025 Travis Fischer