Kubernetes中Pod长期处于Pending状态的排查方法

排查 Pod 长时间处于 Pending 状态，通常按照四个步骤来处理最稳妥：先查看 Events，定位 Pod 被拒绝或无法调度的具体原因；再核对 Node 字段，判断调度是否真正落到了某个节点；接着按照资源、PVC、污点、亲和性的顺序，逐项验证这些最常见、最容易导致 Pending 的问题；最后，再排除节点状态异常、调度器故障，以及命名空间配额限制等系统层面的影响。

Pod 一直处于 Pending 状态，说明它虽然已经被 Kubernetes API Server 成功接收，但可能迟迟没有被调度到任何可用节点上运行，或者看起来已经分配了节点，却卡在启动前的某个关键条件上。大多数情况下，排查线索其实都藏在 Events 中。与其一开始就盲目翻文档，不如先把事件输出看清楚，往往能更快定位问题。

第一步：重点查看 Events，读懂“失败原因”

先执行下面这条命令，直接聚焦关键信息：

重点关注底部的 Events 区块，常见提示通常会直接指向根因：

• 0/3 nodes are a vailable: 3 Insufficient cpu → 资源请求超过节点可分配上限
• pod has unbound immediate PersistentVolumeClaims → PVC 尚未成功绑定 PV
• 0/3 nodes had untolerated taint {key: value} → 节点存在污点，Pod 缺少对应的容忍配置
• failed to pull image → 镜像拉取失败（虽然通常属于 ContainerCreating 阶段，但有时也会出现在 Pending 后续）

如果 Events 为空，或者事件已经被新记录覆盖，可以继续补查历史事件：

第二步：确认 Pod 是否真的完成调度

继续查看 kubectl describe pod 输出中的 Node 字段：

• Node: → 调度器根本没有选中节点，问题通常出在调度阶段，例如资源不足、污点限制、亲和性约束或 PVC 问题
• Node: node-01 → 表示已经调度成功，但卡在容器启动前后阶段，比如镜像拉取、存储挂载、Init 容器执行失败等

这个判断决定了后续排查方向，是 Kubernetes 排查 Pod Pending 状态时非常关键的一步，不能省略。

第三步：逐项验证最常见的高频原因

建议按照实际出现概率从高到低依次检查：

• 资源不足：调度器只看 requests，并不会参考 limits。可以使用 kubectl describe node 查看 Allocatable 与 Allocated resources 对比，确认剩余 CPU、内存、ephemeral-storage 是否大于或等于 Pod 的 requests 总和
• PVC 未就绪：执行 kubectl get pvc -n ，如果状态不是 Bound，就需要继续检查 PV 是否存在、StorageClass 是否可用，以及访问模式是否匹配
• 污点与容忍不匹配：使用 kubectl get nodes -o wide 查看节点信息中的 Taints；再核对 Pod YAML 里的 tolerations 是否完整覆盖所需配置
• 节点标签或亲和性限制过严：运行 kubectl get nodes --show-labels，对比 Pod 的 nodeSelector 或 nodeAffinity 规则，确认至少存在一个节点能够满足全部调度条件

第四步：不要忽略系统级异常

下面这些情况很容易被遗漏，但一旦出现，往往会导致新创建的 Pod 普遍处于 Pending 状态：

• 节点状态异常：执行 kubectl get nodes，确认 Ready 节点数量是否正常；如果存在 NotReady 或 SchedulingDisabled（被 cordon）节点，需要及时恢复，或者通过其他可用节点绕开
• 调度器本身故障：检查 kube-system 命名空间中的 kube-scheduler Pod 是否处于 Running 状态且没有频繁重启；同时查看日志中是否存在 panic、无法连接 etcd 等异常记录
• 命名空间配额耗尽：如果集群启用了 ResourceQuota，可执行 kubectl get resourcequota -n ，查看 status.hard 与 status.used 是否已经达到上限