Kubernetes 如何排查 Pod 长期处于 Pending 状态

Pod长期Pending的排查需分四步：先查Events定位拒绝原因，再确认Node字段判断是否调度成功，接着按资源、PVC、污点、亲和性顺序验证高频问题，最后排除节点状态、调度器故障及命名空间配额等系统异常。

Pod 长期 Pending，说明它已被 API Server 接收，但始终没被调度到节点运行，或虽已分配节点却卡在启动前置条件上。90% 的问题线索藏在 Events 里，别急着翻文档，先看输出。

第一步：盯紧 Events，读出“拒绝理由”

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

kubectl describe pod <pod-name> -n <namespace> | tail -20

重点看底部的 Events 区块，常见提示直指根源：

1. 0/3 nodes are available: 3 Insufficient cpu → 资源请求超限
2. pod has unbound immediate PersistentVolumeClaims → PVC 没绑上 PV
3. 0/3 nodes had untolerated taint {key: value} → 节点有污点，Pod 缺少对应容忍
4. failed to pull image → 镜像拉取失败（虽属 ContainerCreating 阶段，但有时也出现在 Pending 后续）

如果 Events 空白或被刷掉，补查历史事件：

kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name>

第二步：确认是否真被调度了

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

1. Node: <none> → 调度器根本没选中节点，问题在调度阶段（资源、污点、亲和性、PVC）
2. Node: node-01 → 已调度成功，但卡在容器启动环节（镜像、存储挂载、Init 容器失败等）

这个判断是后续排查方向的分水岭，不能跳过。

第三步：逐项验证高频原因

按实际发生概率排序检查：

1. 资源不足：调度只看 requests，不是 limits。用 kubectl describe node <node-name> 查 Allocatable 和 Allocated resources 对比表，确认剩余 CPU / 内存 / ephemeral-storage 是否 ≥ Pod 的 requests 总和
2. PVC 未就绪：执行 kubectl get pvc -n <namespace>，状态不是 Bound 就要查 PV 是否存在、StorageClass 是否可用、访问模式是否匹配
3. 污点与容忍不匹配：用 kubectl get nodes -o wide 看 Taints 列；再核对 Pod YAML 中 tolerations 是否完整覆盖
4. 节点标签或亲和性限制过严：运行 kubectl get nodes --show-labels，比对 Pod 的 nodeSelector 或 nodeAffinity 规则，确认至少有一个节点满足全部条件

第四步：别漏掉系统级异常

这些情况容易被忽略，但一旦出现，所有新 Pod 都会 Pending：

1. 节点状态异常：执行 kubectl get nodes，确认所有 Ready 节点数量正常；若有 NotReady 或 SchedulingDisabled（cordon 过），需恢复或绕行
2. 调度器本身故障：检查 kube-system 命名空间下 kube-scheduler Pod 是否 Running 且无重启；同时确认其日志有无 panic 或连接 etcd 失败记录
3. 命名空间配额耗尽：若启用了 ResourceQuota，运行 kubectl get resourcequota -n <namespace>，查看 status.hard 与 status.used 是否已满