Kubernetes Pod 总是 CrashLoopBackOff？按这 5 步定位

在 Kubernetes 集群里，Pod 一旦进入 CrashLoopBackOff 状态，就说明容器在反复启动后又反复退出，kubelet 正在按退避策略不断重试。遇到这种情况不要只会删 Pod 重建，重启解决不了根本问题。按下面 5 步排查，大多数情况都能在几分钟内找到原因。

第一步：先看 describe，确认退出原因

kubectl describe pod 是定位的起点。重点看 Events、容器状态里的 Last State 和重启次数。Terminated 里的退出码和原因是最直接的线索：退出码 1 通常是应用自身报错退出，退出码 137 往往和内存超限有关，OOMKilled 则明确表示容器因内存不足被系统终止。先确认是应用崩溃、被杀掉，还是根本没有正常启动，再决定下一步往哪个方向查。

kubectl describe pod <pod-name> -n <namespace>
kubectl get pod <pod-name> -n <namespace> -o wide

第二步：看日志，找应用报错

容器退出了，日志是最诚实的证据。用 kubectl logs 看本次运行的输出；如果容器已经重启过多次，记得加 --previous 看上一次退出的日志，很多关键报错只在上一次输出里出现。重点找启动阶段的异常：端口被占用、配置文件解析失败、依赖服务连不上、缺少环境变量，这些都会让进程刚启动就退出。

kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

注意：日志里如果只有一两行就结束，往往是启动命令或配置的问题；如果日志正常输出一段时间后才退出，则更可能是运行中出错或探针、资源方面的问题。

第三步：检查镜像拉取与启动命令

如果 describe 里出现 ErrImagePull 或 ImagePullBackOff，说明问题在镜像本身：镜像名或标签写错、镜像仓库不可达、私有仓库缺少访问凭证，都会导致容器根本拉不下来。核对 Deployment 或 Pod 定义里的镜像地址和标签，确认该标签确实存在。

另外要检查容器的启动命令和参数。镜像的默认入口点被错误的 command 或 args 覆盖、启动脚本路径不存在、启动参数格式不对，都会让容器秒退。可以在本地用同样的镜像和命令先跑一次，确认进程能正常启动。

第四步：检查存活探针与就绪探针

探针配得太苛刻是 CrashLoopBackOff 的常见原因。存活探针（livenessProbe）失败会触发容器重启：如果应用启动较慢，而 initialDelaySeconds 给得太小，探针在应用还没准备好时就开始探测，容器就会被反复杀掉重启。

检查这几点：探针的路径和端口是否与应用实际监听的一致；探测的超时时间和周期是否合理；启动慢的应用是否设置了足够的初始延迟或改用启动探针（startupProbe）。就绪探针（readinessProbe）失败不会重启容器，只会让 Pod 暂时不接收流量，排查时不要把两者混淆。

第五步：检查资源配额与节点容量

容器的 resources.requests 和 resources.limits 配得不合理也会导致反复崩溃。内存 limit 设得比应用实际峰值还低，容器一到高峰就被 OOMKilled；CPU limit 压得太低，应用启动变慢，又会反过来触发探针失败。先看 describe 里的资源配置，再用 kubectl top pod 和 kubectl describe node 看节点剩余容量，确认不是节点资源耗尽导致 Pod 无法正常运行。

kubectl top pod <pod-name> -n <namespace>
kubectl describe node <node-name>

总结：按顺序查，别盲目重启

一套固定的排查顺序能省很多时间：先 describe 看退出码和事件，再 logs 看应用报错，然后核对镜像与启动命令，接着检查探针配置，最后看资源与节点容量。每一步都有明确的输出作为判断依据，定位到哪一步就修哪一步。

平时也建议把探针参数、资源 request 和 limit 按应用实际表现合理设置，启动慢的服务留出足够的初始延迟，并保留关键日志。这样下次再看到 CrashLoopBackOff，就能快速定位，而不是反复重启碰运气。