直接回答：标准顺序：kubectl describe pod 看 events 与 lastState（退出码是钥匙——137=SIGKILL 多为 OOM，1=应用报错，127=命令不存在）；kubectl logs --previous 拿上一次崩溃的日志；查 resources 与 limits 的 OOMKilled 标记；探针配置是否合理（liveness 太激进会在启动慢时误杀）。退出码加日志基本能定方向。
展开解析：退出码速查：0 退出却重启——容器主进程正常结束但 restartPolicy=Always，查是不是把一次性任务跑成了 Deployment；1——应用自身错误，logs --previous 看堆栈，常见配置缺失、依赖服务连不通、端口被占；126/127——入口命令权限或路径错，镜像 CMD 与 command/args 覆盖错配；137——查 containerStatuses 的 reason: OOMKilled，提 limits 或查内存泄漏，注意 JVM/Node 默认堆不按容器限额自适应时的经典踩坑；143——SIGTERM 优雅退出失败被强杀，查 preStop 与 terminationGracePeriodSeconds。平台侧问题的信号：多 Pod 同挂（节点资源压力、镜像仓库故障）、events 里 FailedScheduling/FailedMount 先于崩溃——那根本不是 CrashLoopBackOff 的应用层原因。日志拿不到的补救：崩溃太快没日志——把 command 临时换成 sleep 进容器手动跑入口命令复现；或 kubectl debug --copy-to 起副本折腾。上线预防：liveness 初始延迟给足（initialDelaySeconds 或 startupProbe）、资源限额压测后定、镜像 entrypoint 对配置缺失给出明确报错而非静默退出。
追问方向：OOMKilled 与 cgroup limit 的精确关系？startupProbe 与 liveness 如何配合？
（约 490 字）