Pod Pending 和 CrashLoopBackOff 怎么排查

Kubernetes 排障里，最常见也最能暴露基础功底的两类状态就是：

• Pending
• CrashLoopBackOff

它们看起来都叫“Pod 起不来”，但根因完全不在同一层。

• Pending 往往说明 Pod 还没真正运行起来
• CrashLoopBackOff 往往说明容器已经启动过，但反复失败退出

先说结论

• 看到 Pending，优先查调度、资源、PVC、镜像拉取和节点约束
• 看到 CrashLoopBackOff，优先查容器进程退出原因、配置错误、探针和依赖初始化
• 先分清“Pod 没被调度”还是“容器启动后反复挂”，排障效率会高很多
• describe pod、事件、容器日志和前一次日志是最核心的四个入口

先建立一个排障分层

可以把一个 Pod 正常上线分成四层：

1. 调度层: 能不能找到节点
2. 启动层: 镜像、卷、配置能不能准备好
3. 进程层: 容器主进程能不能启动成功
4. 健康层: 探针是否通过，能不能接流量

Pending 主要卡在前两层，CrashLoopBackOff 主要卡在后三层。

Pending 怎么查

先看事件

第一步几乎永远是：

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

重点看 Events。
很多 Pending 原因会直接写在这里，比如：

• 0/6 nodes are available: insufficient cpu
• pod has unbound immediate PersistentVolumeClaims
• node(s) had taint that the pod didn't tolerate

常见原因一: 资源不足

最常见的是 request 配太高，集群没有足够 CPU 或内存可调度。

排查重点：

• Pod 的 request/limit
• 节点剩余 allocatable
• 是否有 HPA 或批量发布导致瞬时资源吃满

常见原因二: PVC 未绑定

如果 Pod 依赖 PVC，而存储类、PV 或动态供给有问题，Pod 会一直 Pending。

这类排查要顺着看：

• PVC 状态
• StorageClass
• PV 是否可用

常见原因三: 节点亲和或污点容忍不匹配

典型情况：

• 指定了 nodeSelector，但集群没有满足条件的节点
• 节点有 taint，Pod 没有 toleration

常见原因四: 镜像拉取前置失败

有些场景状态看似 Pending，但本质上已经卡在容器创建前阶段，像：

• 镜像仓库鉴权失败
• 镜像地址错误

这时也要结合 Events 看 ErrImagePull、ImagePullBackOff。

CrashLoopBackOff 怎么查

CrashLoopBackOff 的意思不是“启动失败一次”，而是：

• 容器启动过
• 很快退出
• Kubernetes 不断重启
• 重启间隔不断退避

第一步看日志

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

尤其 --previous 很重要，因为容器可能已经重启多次，当前实例日志不完整。

高概率原因一: 应用配置错误

比如：

• 环境变量缺失
• 数据库地址配置错
• 配置中心拉取失败
• 启动参数不兼容

这是最常见的一类。

高概率原因二: 依赖初始化失败

例如：

• 连接 DB、Redis、MQ 超时
• 依赖服务 DNS 解析失败
• 下游 TLS 证书错误

很多团队一看到容器反复重启就去怀疑 Kubernetes，实际上是应用启动逻辑自己没过。

高概率原因三: OOMKilled

如果容器启动时内存暴涨，或者 JVM / Node 参数配得过大，容器会被 OOM kill。
这类情况要看：

• kubectl describe pod
• 容器退出码
• 节点和容器的内存配置

高概率原因四: 探针配置过严

应用其实能起来，但启动慢；readiness / liveness 探针配置太激进，导致 kubelet 反复判断失败并重启。

重点看：

• initialDelaySeconds
• timeoutSeconds
• failureThreshold
• 应用真实启动耗时

一条实战排障顺序

如果线上一个新发布的 Pod 起不来，我一般按这个顺序查：

1. kubectl get pod -o wide 看状态和节点
2. kubectl describe pod 看 Events
3. kubectl logs 和 --previous 看容器日志
4. 看 Deployment 最近变更了什么
5. 看 ConfigMap / Secret / 镜像 tag / 资源配置

这样通常 5 分钟内能把问题缩到一个很小的范围。

如何区分是平台问题还是应用问题

更像平台问题

• 调度失败
• PVC 不可用
• 节点污点不匹配
• 镜像拉取失败

更像应用问题

• 进程启动异常
• 配置加载失败
• 依赖连接失败
• 探针参数与应用启动特性不匹配

很多时候这两类会交叉，但先做这个二分，沟通成本会低很多。

为了减少这类故障，平时可以怎么做

• 给关键服务补启动前检查和更明确的错误日志
• 不要把 liveness probe 配得比 readiness 更激进
• 发布前校验镜像、配置、Secret、PVC
• 建立最小化发布检查清单

总结

Pending 和 CrashLoopBackOff 虽然都表现成“Pod 不可用”，但一个偏调度与准备阶段，一个偏容器运行阶段。

真正高效的排障，不是背状态名，而是知道先去哪一层查、看哪几个命令、怎么快速把问题归到平台侧或应用侧。