Kubernetes Kustomize 介绍

介绍

通俗描述

详细解析 kustomize.yaml 文件

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

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

非常简单就是关联了一下对应的资源

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

需要注意一下，prod 目录下和 test 目录下的 kustomize.yaml 配置文件都是修改配置描述，只是不同的环境使用不同的修改层的区别。

这个配置文件主要用来描述我们要修改基础层的那些内容，例如修改名字格式 namePrefix、批量添加标签 commonLabels、镜像替换 images 等。

它解决的主要问题是：

拒绝“复制粘贴”：以前为了区分开发和生产环境，我们得把 1000 行的 YAML 文件复制两份，哪怕其中 990 行都是一样的。现在，那 990 行通用的代码只需要维护一份。

修改一处，处处生效：如果你想升级镜像版本，只需要改“基础款”，所有环境（开发、测试、生产）都会自动用上新镜像，不会漏改。

安全可追溯：所有的修改都是以“补丁文件”的形式存在的，非常适合上传到 Git 仓库。谁在什么时候改了副本数、改了内存限制，清清楚楚。

演示

1. 教程目标

本教程将带您从零构建一个符合行业标准的 Kustomize 项目。我们将通过部署一个 Nginx 应用，一次性演练 Kustomize 的六大核心功能：

Base/Overlay 架构：多环境复用（测试环境与生产环境共用一些基础配置）。

namePrefix：资源命名空间隔离（资源名称格式化）。

commonLabels：全资源统一标签（添加统一 label 方便管理）。

images：镜像版本统一替换（批量替换镜像）。

Patches：属性修改与容器挂载点注入。

ConfigMap Generator：配置变更触发 Pod 自动重启（杀手锏）。

2. 准备工作：目录结构

首先，我们建立一个标准的 Kustomize 目录结构。

打开终端，执行以下命令：

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

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

3.1 创建 Deployment

文件路径：base/deployment.yaml

3.2 创建 Service

文件路径：base/service.yaml

3.3 创建 Base 索引文件

文件路径：base/kustomization.yaml

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

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

4.1 准备配置文件素材

文件路径：overlays/prod/config/index.html

4.2 编写补丁 (Patch)

我们需要修改 Base 中的 Deployment。这里演示了修改字段（改副本数）和注入新结构（挂载 Volume）两种操作。

文件路径：overlays/prod/patch-deployment.yaml

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

这是本教程最重要的文件，它组装了所有功能。

文件路径：overlays/prod/kustomization.yaml

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

5.1 执行构建

在 kustomize-demo 根目录下运行：

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

请观察终端输出的 YAML，您会看到以下变化：

名称变化：Deployment 名字变成了 prod-my-nginx（前缀生效）。

标签变化：所有资源都多了 env: production（标签生效）。

镜像变化：image 变成了 nginx:1.21（镜像替换生效）。

结构变化：Deployment 里多了 replicas: 3 和 volumeMounts（补丁生效）。

Hash 魔法：ConfigMap 名字变成了类似 prod-site-config-ck7bg9k276，且 Deployment 里的引用也自动变成了这个带 Hash 的名字。

应用验证

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

1. 执行 kubectl apply -k

2. 设置端口转发

3. 通过浏览器查看结果

4. 修改配置

修改 overlays/prod/config/index.html 的内容：

5. 再次构建并设置转发

再次运行 kubectl kustomize overlays/prod。

6.观察差异

你会发现：

ConfigMap 的名字后缀变了（例如从 ck7... 变为 f7m...）。

Deployment spec.template.spec.volumes 中引用的 ConfigMap 名字也随之改变。

7. 结论

当您将这个新的 YAML 应用到集群 (kubectl apply) 时，Kubernetes 会检测到 Deployment 的定义发生了变化（因为引用的 ConfigMap 名字变了），从而立即触发 Pod 的滚动更新 (Rolling Update)。

这意味着：您只需修改配置文件，无需手动重启 Pod，新配置即可上线。