常见故障场景二：远程 Base 仓库更新后缓存未失效

在团队协作或 GitOps 工作流中，Kustomize 的远程 Base 通常通过 git 或 https 协议引用。当远程仓库的 YAML 清单发生变更（如 Deployment 镜像版本升级、ConfigMap 数据修改），但本地执行 kustomize build 后输出的内容仍为旧版本时，即发生了“远程 Base 缓存未失效”故障。该问题在 CI/CD 流水线中尤为隐蔽，可能导致生产环境部署了过时的配置。

4.1 故障根因分析

Kustomize 在解析远程 URI 时，默认会基于 URL 的完整路径和 Git 提交哈希（如果指定）生成缓存键。但以下三种场景会绕过或破坏缓存失效机制：

4.2 缓存失效流程示意图

下图展示了从远程 Base 更新到本地缓存失效的完整链路，以及故障发生的具体环节：

4.3 故障复现与验证

以下步骤可复现该故障，并验证缓存未失效的具体表现：

1. 准备远程 Base：在 Git 仓库中创建 base/deployment.yaml，设置镜像为 nginx:1.21。
2. 编写 kustomization.yaml：引用远程 Base，使用分支引用：
   

   apiVersion: kustomize.config.k8s.io/v1beta1
   kind: Kustomization
   resources:
     - https://github.com/team/config-base//base?ref=main

3. 首次构建：执行 kustomize build .，输出中镜像为 nginx:1.21。
4. 更新远程 Base：将远程仓库中 deployment.yaml 的镜像改为 nginx:1.25，提交并推送。
5. 再次构建：再次执行 kustomize build .，输出仍为 nginx:1.21。
6. 验证缓存：查看 ~/.kustomize/cache 目录，发现缓存文件的时间戳未更新。

4.4 解决方案与最佳实践

针对远程 Base 缓存未失效问题，推荐以下三种解决方案，按推荐优先级排列：

4.5 故障排查清单

当怀疑远程 Base 缓存未失效时，按以下清单逐项排查：

• 检查引用方式：确认 kustomization.yaml 中远程 Base 的 ref 参数是分支名还是 commit hash。
• 检查缓存目录：查看 ~/.kustomize/cache 下对应仓库的缓存文件，比对时间戳。
• 检查网络连通性：使用 git ls-remote 验证远程仓库的最新提交是否可达。
• 检查 Kustomize 版本：kustomize version，旧版本（v4.x 以下）的缓存机制存在已知缺陷。
• 检查 CI 环境变量：确认 KUSTOMIZE_CACHE_DIR 是否被设置为持久化路径，导致缓存跨构建复用。