Kubernetes 节点压力排查：Pod Pending 不一定是资源真的不够

Kubernetes 节点压力排查：Pod Pending 不一定是资源真的不够

Kubernetes 里 Pod Pending 很常见。很多人第一眼看到 Pending，就判断集群资源不够，需要扩容。但 Pending 的原因可能是资源不足、亲和性规则、污点容忍、PVC 绑定、镜像拉取、配额限制。扩容不一定解决问题。

排查 Pending，先看调度事件，而不是先加节点。

一、先看事件

flowchart TD
A[Pod Pending] –> B[Describe Pod]
B –> C[Scheduler Events]
C –> D[Resource]
C –> E[Affinity]
C –> F[Taint]
C –> G[PVC]

kubectl describe pod 的事件通常已经给出方向。不要跳过它。

二、资源不足要看 request

kubectl describe pod demo
kubectl top nodes
kubectl get resourcequota -A

调度器看 request，不看实际使用量。节点 CPU 看起来空闲，但 request 已经被预留满，Pod 仍然无法调度。

三、亲和性和污点常被忽略

nodeSelector:
disk: ssd
tolerations:
– key: dedicated
operator: Equal
value: gpu

如果节点标签不匹配，或者 Pod 没有容忍污点，有资源也调不上去。生产集群里这类规则很多，尤其要小心。

四、PVC 也会让 Pod 等待

Stateful 服务 Pending，可能不是计算资源，而是存储卷没绑定。看 PVC 状态和 StorageClass。

kubectl get pvc
kubectl describe pvc data-demo-0

存储问题不要用加计算节点解决。方向错了，只会浪费时间。

还要看调度器日志和节点条件。节点可能处于 MemoryPressure、DiskPressure、PIDPressure，或者被 cordon。Pod 事件里有提示，但节点状态能帮助确认范围。

kubectl get nodes
kubectl describe node node-1
kubectl get events -A –sort-by=.lastTimestamp

如果大量 Pod 同时 Pending，要判断是单命名空间配额问题，还是集群级资源问题。命名空间 ResourceQuota 打满时，加节点也不会让 Pod 调度成功。

排查结论最好写成“不可调度原因 + 证据 + 动作”。比如“缺少 disk=ssd 标签节点，事件显示 node selector 不匹配，动作是补标签或修改调度约束”。这样交接更清楚。

五、总结

Kubernetes Pod Pending 不一定是资源真的不够。排查时先看事件，再看 request、配额、亲和性、污点容忍和 PVC。

扩容是手段，不是诊断。调度原因看清楚，再决定要不要加节点。

Pending 排查越熟练，越能避免无效扩容。Kubernetes 的很多问题，答案已经写在事件里，只是我们太急着跳到结论。

生产里还要把 Pending 按原因聚合。单个 Pod Pending 是局部问题，大量 Pod 因同一个原因 Pending，就是平台问题。

pending_dashboard:
unschedulable_by_resource
unschedulable_by_affinity
pvc_pending
quota_exceeded

有了聚合视图，平台团队能提前发现调度约束过严、某类节点不足或存储供应异常，而不是等业务团队逐个报障。