Pod 处于 CrashLoopBackOff 状态，监控上如何快速定位根因？

CrashLoopBackOff 可以说是最让新手头疼、也最常见的 Pod 状态之一。它表示容器启动后很快退出，kubelet 在不断重试，且每次重试的间隔越来越长（指数退避）。

排查的核心心法：正确的顺序比盲目的动作更重要。不要一上来就 kubectl delete pod，删了也只是让它重新走一遍崩溃流程，问题还在。

第一步：看事件（Events）

执行：

kubectl describe pod <pod-name>

经验之谈：80% 的问题会直接显示在 Events 里。常见的线索包括：

• OOMKilled：内存超出 limit 被内核杀掉；
• FailedScheduling：调度失败（资源不足、节点亲和性不满足等）；
• BackOff / ImagePullBackOff：镜像拉取失败。

第二步：看上一次崩溃的日志

容器已经重启过，当前日志看不到崩溃现场，要用 --previous 拉取上一次退出容器的日志：

kubectl logs <pod-name> --previous

这条命令往往能让你直接拿到程序崩溃的堆栈信息（stack trace），是定位根因最快的一招。

小结

先 describe 看事件，再 logs --previous 看崩溃堆栈，绝大多数 CrashLoopBackOff 都能在两步之内定位。