现场是这样的。Pod 状态在运行和等待之间循环，重启次数不断累加，业务一直没有就绪，服务不可用。
把日志和配置对完，能解释这个现象的基本就这几处。应用启动时依赖的服务还没就绪；启动参数或者环境变量缺失，进程直接退出；资源限制太小，进程被系统杀掉。
第一件事是看退出原因和重启次数
kubectl describe pod 名称 | grep -A5 'Last State'再往下看上一次崩溃前的日志
kubectl logs 名称 --previous --tail 100接着核对环境变量与配置
kubectl exec -it 名称 -- env | head -20剩下的就是确认资源限制是否合理
kubectl get pod 名称 -o jsonpath='{.spec.containers[*].resources}'手上没有现成的复现脚本，就照着线上请求手工拼了一个。
怎么算真的好了，看的是同一批现象。Pod 稳定运行且就绪探针通过，重启次数不再增长。
这里还有个坑。日志为空时优先怀疑启动命令和配置缺失；加了就绪探针之后，依赖没起来也不会被流量打进来。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。