Pod 出现 CrashLoopBackOff 该如何系统性排查？

结论：CrashLoopBackOff 表示容器反复启动即退出、kubelet 按退避策略（10s 起翻倍至 5min 上限）不断重启。排查主线是：退出原因（exit code）→ 容器日志 → 事件 → 配置与依赖逐项排除。

展开：标准流程：1）kubectl describe pod 看 Last State 的 exit code 和事件——137=SIGKILL 通常是 OOMKilled（看 Reason 确认，调大 memory limit 或查内存泄漏）；143=SIGTERM 多为 liveness 探针杀死；1/2/126/127 多为应用自身错误、入口命令不存在或不可执行。2）kubectl logs <pod> --previous 拿上一个崩溃实例的日志，这是最关键一步，当前实例可能还没输出。3）查配置类问题：镜像名写错是 ImagePullBackOff（不属于崩溃）；ConfigMap/Secret 的 key 缺失、volume 挂载失败、环境变量拼错都很常见。4）资源类：limits 过小 OOM、节点磁盘压力。5）依赖类：应用启动强依赖的下游（数据库、注册中心）不可用，应加重试或 initContainer 等待。调试技巧：kubectl debug 创建 ephemeral debug 容器进 Pod 网络命名空间排查；镜像无 shell 时用 kubectl debug --copy-to --image=busybox 换入口起副本。回答时强调「先定 exit code，再看 previous 日志」的方法论比罗列命令更加分。