Kubernetes Pod 排错实战：从 Pending 到 CrashLoopBackOff

面向 K8s 常见 Pod 状态异常，给出从 Pending、ContainerCreating 到 CrashLoopBackOff 的逐层定位路径与常用诊断命令。

生产环境里，Pod 不健康是最高频的告警。本文把最常见的几类状态串成一条排障路径，配上手边常备的命令。

Pending：调度器没给 Pod 安排节点。kubectl describe pod 看 Events，常见三类原因：节点资源不够（Insufficient cpu/memory）、节点污点没容忍（node 有 taint 但 pod 没配 toleration）、PVC 没绑定成功（存储类或容量不足）。

ContainerCreating：调度成功但容器起不来。重点看拉镜像（是不是 tag 写错、私有仓库没配 imagePullSecrets）、挂载卷失败（PVC/ConfigMap/Secret 名字不对）、以及探针把容器卡死在启动阶段。

CrashLoopBackOff：容器反复崩溃重启。这是「应用自己有问题」。kubectl logs <pod> --previous 看上一次崩溃前的日志；如果日志都打不出来，kubectl exec 进去 strace -e execve /app 看进程到底卡在哪。

OOMKilled：退出码 137。describe 里会明确写 OOMKilled，多半是 limits.memory 设得比实际峰值低，或应用有内存泄漏。别一上来就加 limit，先用 top 观察实际曲线，再决定。

一条经验：排障顺序永远是「事件 → 日志 → 进容器」，由外到内。Events 是系统层，日志是应用层，进容器是最后手段（很多 CrashLoop 状态根本进不去）。把 describe、logs --previous、exec 三个命令练成本能反应，K8s 的日常排障就稳了。