Kubernetes Pod 一直 Pending 的五类原因与排查顺序

Kubernetes 里 Pod 一直 Pending，绝大多数情况不是调度器坏了，而是资源不够或约束不满足。这篇按排查效率排序，把五类最常见原因列清楚。

一、先看事件，不要猜

kubectl describe pod <name> -n <ns> | sed -n '/Events/,$p'
kubectl get events -n <ns> --sort-by=.lastTimestamp | tail -20

Events 里第一句话基本就是答案：Insufficient cpu、node(s) had taint、didn't match Pod's node affinity、persistentvolumeclaim not found，四类占了九成。

二、资源请求超过节点可分配量

kubectl describe node <node> | grep -A8 "Allocated resources"

注意看的是 Allocatable 而不是 Capacity——kubelet 预留、系统进程占用的部分不能给业务用。request 总和超过 Allocatable 就会 Pending，即使节点看起来「还有很多空闲内存」。

三、污点与容忍不匹配

控制面节点默认带 node-role.kubernetes.io/control-plane:NoSchedule。业务 Pod 没有对应 toleration 就永远调度不上去。查法：

kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

四、亲和性与反亲和性写反了

requiredDuringSchedulingIgnoredDuringExecution 是硬约束，条件不满足直接 Pending；preferred 是软约束只影响打分。常见错误是把硬约束写成了必须落在某个 label 的节点上，而那个 label 根本没人打。

五、PVC 卡住没绑定

有状态服务常见。Pod 会一直等 PVC，PVC 又等 StorageClass 供应 PV：

kubectl get pvc -n <ns>
kubectl describe pvc <name> -n <ns>

如果 StorageClass 是 WaitForFirstConsumer，那 PVC Pending 是正常的，真正要看的是 Pod 为什么没被调度。

快速定位顺序

1. describe pod 看 Events 第一句
2. 看节点 Allocatable 剩余量
3. 查污点与 toleration
4. 查亲和性硬约束
5. 有状态服务查 PVC

按这个顺序走，通常两分钟内能定位，比反复重启 Pod 有效得多。