Kubernetes Pod 一直 CrashLoopBackOff，按这五步定位

CrashLoopBackOff 不是一个独立故障，它是 kubelet 反复重启容器后给出的状态。真正的原因永远在 pod 的上一轮生命周期里，所以第一步不是看状态，是看现场。

第一步，看退出码。kubectl describe pod 里 Last State 的 Exit Code 是关键。退出码 0 或 1：应用自己崩了，多半是配置缺失或依赖连不上。退出码 137：被 SIGKILL，典型的 OOMKilled 或被 liveness 探针杀掉。退出码 143：收到 SIGTERM，被优雅终止，通常是探针配置把还活着但不响应的进程判死了。

第二步，看日志的上一轮。kubectl logs <pod> --previous 才能拿到崩溃前的输出，不带 --previous 只能看到当前空容器，什么都看不到。这一步九成的人会漏。

第三步，分开判断启动失败和运行中断命。如果 pod 启动后几秒就崩，是初始化逻辑问题：环境变量、挂载路径、数据库连接串。如果跑了一阵才崩，看内存曲线和探针阈值。

第四步，查探针。livenessProbe 的 initialDelaySeconds 和 timeoutSeconds 是最常见的误杀来源。Java 应用冷启动经常超过 30 秒，探针 10 秒就开始打，打不通就重启，重启后更慢，进入死循环。规范做法是 liveness 给足 initialDelay，或者干脆只用 readiness 加 startupProbe。

第五步，查资源。requests 设太小会被调度到资源紧张的节点，limits 设太小会 OOMKilled。检查 kubectl describe 里的 Last State Reason 是不是 OOMKilled，指标上看 container_memory_working_set_bytes 有没有贴着 limit。

最后说一个容易被忽略的点：ConfigMap 或 Secret 变更不会自动重启用挂载方式的 pod，但用环境变量注入的，重启一次就换了新值。所以配置改了之后出现的崩溃，先确认容器里拿到的是哪一版配置。