3. Kustomize 工作流深度解析：资源读取、Overlay 合并、Patch 应用、输出渲染的全链路拆解

要优化 Kustomize 配置缓存的命中率，首先必须精确理解 Kustomize 在每次构建时执行的完整工作流。Kustomize 并非简单的“读取-合并-输出”三步，而是一个包含资源发现、多层级 Overlay 合并、Patch 策略应用、变量注入与最终渲染的复杂管道。本章将逐层拆解这一全链路，并标注每个环节的缓存关键点。

3.1 全链路四阶段总览

Kustomize 的构建过程可以抽象为四个核心阶段。每个阶段对文件系统的访问模式不同，直接影响缓存策略的设计。

3.2 阶段一：资源读取与依赖解析

工作流从 kustomization.yaml 的解析开始。Kustomize 会构建一个完整的资源依赖图，这个过程包含三个子步骤：

1. 入口解析： 读取根目录下的 kustomization.yaml，提取 resources、bases、components 字段。
2. 递归加载： 对每个引用的路径，Kustomize 会检查该路径是否包含另一个 kustomization.yaml。如果是，则递归进入该目录并重复步骤 1；如果不是，则直接读取 YAML 文件作为原始资源。
3. 远程资源获取： 支持从 Git 仓库或 HTTP URL 加载资源。每次构建都会重新拉取远程内容，除非使用本地缓存。

以下 SVG 展示了资源读取阶段的依赖解析过程：

3.3 阶段二：Overlay 合并策略

Overlay 合并是 Kustomize 的核心能力，它实现了“基础配置 + 环境差异”的声明式管理。合并过程遵循严格的优先级规则：

• 基础层 (Base)： 提供通用配置，如 Deployment 的镜像仓库、Service 的端口定义。
• 中间层 (Overlay)： 每个 overlay 目录代表一个环境（dev/staging/prod），可以修改 base 中的字段。
• 组件层 (Components)： 可复用的配置片段，可以注入到任意 overlay 中。

合并算法采用 深度优先、后进先出 的策略。当多个 overlay 修改同一个字段时，最后声明的 overlay 拥有最高优先级。

3.4 阶段三：Patch 应用机制

Patch 应用是 Kustomize 中最灵活也最消耗计算资源的阶段。Kustomize 支持两种 Patch 类型：

1. Strategic Merge Patch (SMP)： 基于 Kubernetes 原生资源结构的智能合并。它理解数组的 patchStrategy 注解，可以按 name 或 key 合并列表项。
2. JSON Patch (RFC 6902)： 通过 add、remove、replace 操作直接修改资源。性能更高，但需要精确指定路径。

Patch 应用的执行顺序直接影响最终结果：

# kustomization.yaml 中的 Patch 声明顺序
patches:
  - path: patch-resource-limits.yaml   # 先执行
  - path: patch-replicas.yaml          # 后执行，覆盖前者
  - target:
      kind: Deployment
      name: web-app
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 10

3.5 阶段四：输出渲染与变量注入

最终阶段负责将合并后的资源转换为可部署的 YAML。此阶段包含两个关键子过程：

• ConfigMap/Secret 生成器： configMapGenerator 和 secretGenerator 会读取文件内容并生成对应的 Kubernetes 资源。生成器的哈希值会作为资源名称的后缀。
• 变量替换： vars 字段允许将资源中的字段值注入到其他资源的字段中。例如，将 Service 的 clusterIP 注入到 Deployment 的环境变量中。

以下 SVG 展示了从合并到最终输出的完整渲染链路：

3.6 全链路缓存关键点总结

基于以上拆解，我们可以识别出四个阶段的缓存关键点：