使用Kustomize更新镜像后未替换Pod反而创建重复Pod问题排查

以下是针对性的排查步骤：

1. 验证Kustomize生成的Deployment资源是否正确 #

先单独执行kustomize build .，检查输出的Deployment内容：

• 确认spec.template.spec.containers[0].image是否已经替换为新的镜像地址和标签
• 检查Deployment的metadata.name、metadata.namespace是否和你之前直接apply的原始Deployment完全一致。如果名称/命名空间不同，kubectl会将其视为新资源，自然会创建新Pod。

2. 检查Kustomize镜像替换规则的匹配性 #

你的kustomize.yaml中images字段的name需要和原始deployment.yaml里的镜像名称匹配（可以是完整镜像名含tag，也可以是不带tag的前缀）：

• 比如原始deployment.yaml里的镜像写的是repo.pkg.dev/PROJECT/REPO/IMAGE（不带tag），但你在kustomize.yaml里的name写了带旧tag的完整路径，这会导致替换不生效。若此时你同时修改了其他字段，可能触发新资源创建。
• 建议将images里的name改为不带tag的镜像前缀，比如repo.pkg.dev/PROJECT/REPO/IMAGE，这样无论原始镜像带什么tag，都能正确替换。

3. 排查Kustomize是否意外修改了资源标识 #

检查你的kustomize.yaml及相关配置：

• 有没有设置namePrefix、nameSuffix字段，导致Deployment名称被添加前缀/后缀
• 有没有通过namespace字段指定了和原始资源不同的命名空间
• 有没有其他patches或transformers修改了Deployment的metadata.labels等关键标识字段——kubectl是通过metadata.name、namespace和apiVersion/kind来识别资源是否为同一对象的，这些字段变化都会导致创建新资源。

4. 对比直接apply和Kustomize生成yaml的差异 #

分别执行以下命令，对比两个输出的Deployment资源：

# 直接apply的dry-run输出
kubectl apply -f deployment.yaml --dry-run=client -o yaml > direct-apply.yaml
# Kustomize生成后的dry-run输出
kubectl apply -f <(kustomize build .) --dry-run=client -o yaml > kustomize-apply.yaml

用diff工具对比两个文件，重点看metadata下的所有字段，以及spec中可能触发资源重建的配置（比如selector、template.metadata.labels）。如果这些字段存在差异，kubectl会判断为新资源。

5. 检查集群中是否存在重复的Deployment #

执行kubectl get deployments，查看是否有名称相似或相同但命名空间不同的Deployment。如果存在两个Deployment，自然会产生两组Pod；此时可以删除多余的Deployment，再重新执行Kustomize的apply命令。

6. 验证滚动更新策略是否正常 #

如果Deployment名称一致，但依然出现重复Pod，检查Deployment的滚动更新配置：

• 查看spec.strategy.rollingUpdate.maxSurge是否设置过大（比如设为100%会导致更新期间同时存在新旧Pod），但这种情况属于正常的滚动更新过程，更新完成后旧Pod会被删除。如果旧Pod一直存在，可能是更新过程卡住了，可执行kubectl describe deployment <deploy-name>查看事件日志。

内容的提问来源于stack exchange，提问作者Naji