先看退出码
CrashLoopBackOff 表示 kubelet 正在重启不断退出的容器。重启策略本身在工作，问题在应用或其配置。先用 kubectl describe pod 找到最后一次终止原因和退出码。137 通常是 SIGKILL，往往是 OOM kill；1 是通用应用错误；143 是 SIGTERM，常见于存活探针失败或关闭流程。
kubectl describe pod api-7d9f -n prod | sed -n '/Events:/,$p'
kubectl logs api-7d9f -n prod --previous区分故障类别
缺少 secret 或 config map 会在上一次日志中给出明确错误。OOM kill 会显示 OOMKilled，Pod spec 中也能看到内存限制。存活探针失败会显示探针事件，且往往没有应用错误，因为进程本身健康只是慢。命令错误会立刻以 shell 错误退出。每类问题修法不同；提高重启次数或关闭探针都解决不了。
探针与启动
启动慢的应用配激进存活探针，可能在初始化完成前被杀。应添加 startup probe，或增大 liveness 的 initialDelaySeconds，并把 readiness 分开。存活探针应测试进程本身，而不是可能临时故障的依赖；否则数据库故障会让每个 Pod 重启。
修复与验证
修复配置、命令、内存限制或探针后，确认 Pod 变为 Ready 且重启计数不再增长。删除 Pod 让控制器重建，证明修复能经受全新调度。对照限制观察内存和 CPU；贴着限制运行的应用在流量高峰时会再次崩溃。