kubectl Patch Deployment切换ConfigMap后Pod仍用旧配置问题排查

以下是逐一排查的步骤：

• 确认Deployment的ConfigMap引用是否更新成功
  执行kubectl get deployment test-api -o yaml，查看spec.template.spec.containers下的envFrom（环境变量挂载）或volumes（卷挂载）配置，确认ConfigMap名称是否已经改为actual-url-config。有可能Job执行的patch命令路径错误、名称拼写失误，导致引用根本没更新。

• 验证Pod实际加载的ConfigMap
  找到重启后的目标Pod，执行kubectl exec <pod-name> -- env（环境变量挂载场景），或者kubectl exec <pod-name> -- cat /path/to/mounted/config（卷挂载场景），查看实际生效的配置内容。也可以用kubectl describe pod <pod-name>，检查Volumes部分关联的ConfigMap名称是否正确。

• 检查目标ConfigMap的内容正确性
  执行kubectl get configmap actual-url-config -o yaml，确认里面的配置项确实是预期的真实URL，而非和mock-url-config内容一致，或者存在配置项缺失的情况。

• 确认滚动更新是否真正触发并完成
  执行kubectl rollout status deployment/test-api，查看滚动更新是否已完成，新Pod是否处于Running状态。可能存在Job权限不足导致rollout restart未执行成功，或者新Pod因镜像拉取失败、资源不足等原因无法启动，旧Pod仍在提供服务。

• 检查Deployment的滚动更新策略
  查看Deployment的spec.strategy配置：如果是Recreate类型，确认旧Pod是否被正常删除；如果是RollingUpdate，检查maxUnavailable和maxSurge的设置是否合理，是否导致旧Pod未被替换。另外，检查Pod的就绪探针配置，如果新Pod未通过就绪探针，流量会继续指向旧Pod。

• 查看Job的执行日志
  找到执行patch和restart操作的Job对应的Pod，执行kubectl logs <job-pod-name>，检查命令是否有报错（比如ServiceAccount无Deployment更新权限、资源名称错误等），确认patch和restart命令是否实际执行成功。

• 排查应用层配置缓存
  如果应用本身存在配置缓存机制，即使Pod加载了新的ConfigMap，应用也可能未主动读取新配置。可以查看应用日志确认配置加载情况，或在Pod内触发应用配置重载（比如发送SIGHUP信号、调用应用内置的重载接口）。

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