Kustomize：声明式K8s配置管理与覆盖

可视化演示

展示Kustomize的Base/Overlay分层覆盖架构、Patches补丁机制与Helm对比，直观理解K8s声明式配置管理的核心原理。

Kustomize 引入

周姐的工作台上贴着三张便利贴：一张是“户型图集”，一张是“楼盘改动说明”，还有一张是“出图流程”。她不会一张张手绘图纸，而是把原图扫描进电脑，在改动说明里记差异，最后按下按钮，电脑自动合成新版图纸。Kustomize 做的事情，就是 Kubernetes 世界里的这台“合成打印机”。

在 K8s 集群中，每个服务都要写一堆 YAML 描述文件。开发环境、测试环境、生产环境的差异又让这些文件翻倍：单是 nginx 部署，你可能就要维护三份几乎相同的 deployment 文件。Kustomize 通过一个特殊的目录结构来解决这个问题，入口是每个目录中的 kustomization.yaml。

kustomization.yaml 是声明式配置的核心：它用“声明”代替“脚本指令”，明确列出要用哪些资源、要加哪些补丁。Kustomize 没有模板引擎——不会用 {{变量}} 语法做渲染，而是直接组合 YAML。你可以在 kustomization.yaml 中声明 resources、patches、transformers 等字段，然后用 kubectl apply -k 或 kustomize build 得到最终结果。

所以，只要把“图集”和“改动说明”整理好，周姐的“出图流水线”就永远稳定：同一套输入，永远生成同一套输出。这正是 Kustomize 被 GitOps 偏爱的原因——可预测、可审计、可重复。

Base 基础层

标准两居室户型图集是周姐的看家底本。无论哪个楼盘项目，她都先拿出这本图集：客厅和卧室的尺寸、厨房与卫生间的位置、水电管线的走向——一切都已定稿。图集本身不关心楼盘在哪个城市，也不关心买家预算，它就是“标准答案”。

在 Kustomize 中，base 目录就是这套“标准户型图集”。它是一组与环境无关的 K8s 资源文件，比如 Deployment、Service、ConfigMap。base 中定义了服务的通用镜像、端口、挂载点等，这些内容在 dev、staging、prod 之间保持一致。

base 目录也需要有自己的 kustomization.yaml，在其中用 resources 字段列出所有资源文件。这里的资源集合应尽量避免环境差异——不要出现特定环境的域名、实例数量或专属标签。这类差异应当放到 overlay 层去处理，让 base 保持“干净通用”。

一套底图，十个楼盘都能用。base 的质量直接决定后续所有 overlay 的体验：底图越干净，改动说明就越简单。

Overlay 覆盖层

开发商拿来周姐的底图，提出了新要求：“东边楼盘厨房台面换大理石，西边楼盘门把手换金色”。周姐不会去复印店把整本图纸重画，而是在电脑里建一个“楼盘专属改动层”，每次出图时把底图和改动层叠在一起。

overlay 目录是 base 上叠加的“差异层”。它有自己的 kustomization.yaml，里面用 resources 引用 base 目录的位置，再用 patches 或 transformers 描述要改什么。构建时，Kustomize 会先读取 base 的资源，再依次应用 overlay 上的定制内容。

多环境实践通常把 overlay 按环境组织：overlays/dev、overlays/prod。每个 overlay 都引用同一个 base，环境之间只差差异本身。overlay 还可以继续叠加，构建时按声明顺序进行资源合并。

底图不用动，overlay 画多少就改多少。周姐只需要给每个小区单独准备一张“透明贴纸”，贴纸撕掉，底图还是那张干净的底图。

Patches 定制

如果开发商说“东边楼盘所有 132 户型的主卧飘窗要加宽 30 厘米”，周姐不需要去重画那页图纸——她只需要在改动说明里记录：定位到主卧飘窗，宽度 +0.3 米。这就是一个“补丁”：只改局部，不碰整体。

Kustomize 的 patches 字段就是干这个的。它提供了一种精确修改资源的方式，不用在 overlay 里重写整个 YAML 文件，而是通过 target 选择目标资源，再用补丁内容指定修改细节。

Patches 的常用类型有两种。第一种是 strategic merge patch：patch 中给出部分字段，Kustomize 按路径与 base 资源合并；字段标量被覆盖、新字段被添加、列表按 name 合并。第二种是 JSON patch：以 JSON 操作指令数组（如 add/replace/remove）精确定位路径，适合那些 strategic merge 无法表达的情形。kustomization.yaml 中可以使用 patches 字段配合 target 进行定位。

补丁是一种优雅的“微创手术”——不重建，只缝合。

Transformers 变换

周姐同时接了好几个楼盘的订单，每个楼盘要发的风格不同：一号楼全部统一装金色门把手，二号楼全部换灰色踢脚线。“给所有房间统一换一种东西”的需求，如果逐页标注就太蠢了。

Kustomize 的 transformers 就是这种“全局微整形”。它在构建时对所有资源统一施加变换，不需要每个文件单独写补丁。常见变换有：namePrefix 给所有资源统一加前缀，commonLabels 加上公共标签，images 更新镜像，namespace 统一设置命名空间。

transformers 的威力在于“批量”与“一致”。例如 namePrefix 在多个环境有同名资源时（如 prod 和 dev 都叫 nginx）可以避免冲突；commonLabels 让跨环境筛选资源变得容易。变换是有顺序的，组合顺序决定最终结果。

给所有门装统一拉手，不需要一张张改图纸——写一次变换规则就够了。

Helm 对比

还有一种常见的装修方式：买一套“预制家具包”，内含图纸、零件、安装说明书，按照说明书填写一些选项（沙发颜色、桌子尺寸）就能组装出成品。这是 Helm 的方式。周姐的“底图+改动说明”则是另一条路。

Helm 用模板 + Values 渲染 Chart，Kustomize 用 base + overlay 合成配置。两者目标相同——管理多变的 K8s 配置，但理念差异很大：Helm 模板引擎可以在 YAML 里写循环和条件；Kustomize 完全拒绝模板语法，保持 YAML 的原貌。

适用场景上，Helm 适合把整个应用打包交付给陌生用户（比如开源 redis chart），安装简单、版本明确。Kustomize 适合在已有的内部配置上进行增量定制，特别是“以我的 base 为核心”的场景。复杂度取舍上，Helm 学习成本高一些，Kustomize 更直观但实现不了复杂的编排逻辑。两者还可以组合：Helm 渲染出初始 YAML，再用 Kustomize overlay 做二次覆盖。

预制家具和现场定制各有拥趸；但真正聪明的甲方，往往会先买预制家具，再请周姐上门做局部改动。

GitOps 工作流

周姐从土建开始便和所有开发商约定：所有设计图必须存进公司文档库，版本要可追溯，禁止在施工现场改图。开工时，施工队直接从文档库拉最新图纸施工。这就是装修界的“GitOps”。

GitOps 是一种以 Git 为唯一事实来源的部署方式。Kustomize 的配置（base + overlay）整体提交到 Git，CI/CD 或 ArgoCD 在部署时从 Git 拉取目录并执行 kustomize build，然后 apply 到集群。配置文件在 Git 中经历评审、合并、审计，这让多环境之间的差异清晰可见。

ArgoCD 内置 Kustomize 支持，可直接将 Application 的 path 指向 overlay 目录。Git 中的 overlay 更新后，ArgoCD 自动或手动同步，将构建结果应用到目标集群。因为 base 和 overlay 分开维护，环境之间的唯一差异点就是 overlay，这大大降低了环境配置漂移的风险。

周姐的文档库解放了所有项目：改动有人审批，出图自动完成，施工队永远照着最新版本做——而 GitOps 就把这种安全感带给了你的集群。

AI 应用场景

Python 演示

import copyimport json  def merge_dict(base, overlay):    """递归合并字典：标量值以 overlay 为准"""    result = copy.deepcopy(base)    for key, value in overlay.items():        if key not in result:            result[key] = copy.deepcopy(value)        elif isinstance(result[key], dict) and isinstance(value, dict):            result[key] = merge_dict(result[key], value)        elif isinstance(result[key], list) and isinstance(value, list):            result[key] = merge_list(result[key], value)        else:            result[key] = copy.deepcopy(value)    return result  def merge_list(base_list, overlay_list):    """列表合并：按 name 键定位已有项，找不到则追加"""    result = copy.deepcopy(base_list)    for item in overlay_list:        if isinstance(item, dict) and "name" in item:            for i, exist in enumerate(result):                if isinstance(exist, dict) and exist.get("name") == item["name"]:                    result[i] = merge_dict(exist, item)                    break            else:                result.append(copy.deepcopy(item))        else:            result.append(copy.deepcopy(item))    return result  BASE = {    "apiVersion": "apps/v1",    "kind": "Deployment",    "metadata": {"name": "nginx", "labels": {"app": "nginx"}},    "spec": {        "replicas": 3,        "template": {            "spec": {                "containers": [{"name": "nginx", "image": "nginx:1.25"}]            }        }    },} OVERLAY = {    "metadata": {"labels": {"env": "prod"}},    "spec": {        "replicas": 5,        "template": {            "spec": {                "containers": [{"name": "nginx", "image": "nginx:1.26"}]            }        }    },} if __name__ == "__main__":    result = merge_dict(BASE, OVERLAY)    print(json.dumps(result, indent=2, ensure_ascii=False))

1. result = copy.deepcopy(base)深拷贝 base，构建过程不修改原配置。
2. elif isinstance(result[key], dict) and isinstance(value, dict):两个字典相遇时递归合并，这是 Kustomize 合并的基础。
3. elif isinstance(result[key], list) and isinstance(value, list):两个列表相遇时走 merge_list，按 name 字段定位。
4. result[i] = merge_dict(exist, item)找到同名列表项后递归合并，类似 strategic merge patch。
5. else: result.append(copy.deepcopy(item))for-else 结构，未匹配到 name 时才追加新项。
6. print(json.dumps(result, indent=2, ensure_ascii=False))输出合并结果，labels 被叠加、replicas 变成 5、镜像更新为 1.26。

常见误区

面试题