Pod长期Pending的排查需分四步：先查Events定位拒绝原因，再确认Node字段判断是否调度成功，接着按资源、PVC、污点、亲和性顺序验证高频问题，最后排除节点状态、调度器故障及命名空间配额等系统异常。
Pod 长期 Pending，说明它已被 API Server 接收，但始终没被调度到节点运行，或虽已分配节点却卡在启动前置条件上。90% 的问题线索藏在 Events 里，别急着翻文档，先看输出。
第一步：盯紧 Events，读出“拒绝理由”
执行这条命令，直接聚焦关键信息：
kubectl describe pod重点看底部的 Events 区块，常见提示直指根源：
- 0/3 nodes are available: 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 空白或被刷掉，补查历史事件：
第二步：确认是否真被调度了
继续看 kubectl describe pod 输出中的 Node 字段：
-
Node:
→ 调度器根本没选中节点，问题在调度阶段（资源、污点、亲和性、PVC） - Node: node-01 → 已调度成功，但卡在容器启动环节（镜像、存储挂载、Init 容器失败等）
这个判断是后续排查方向的分水岭，不能跳过。
第三步：逐项验证高频原因
按实际发生概率排序检查：
-
资源不足：调度只看
requests，不是 limits。用kubectl describe node <node-name></node-name>查 Allocatable 和 Allocated resources 对比表，确认剩余 CPU / 内存 / ephemeral-storage 是否 ≥ Pod 的 requests 总和 -
PVC 未就绪：执行
kubectl get pvc -n <namespace></namespace>，状态不是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-schedulerPod 是否 Running 且无重启；同时确认其日志有无 panic 或连接 etcd 失败记录 -
命名空间配额耗尽：若启用了 ResourceQuota，运行
kubectl get resourcequota -n <namespace></namespace>，查看status.hard与status.used是否已满
