Kubernetes 2026年6月13日 1 分钟阅读

Pod Pending：调度失败的证据链与处理顺序

从调度事件、资源请求、亲和性、污点和存储绑定定位 Pod 长时间 Pending。

Kubernetes 调度 Pending

文章目录 · 3 节

Pod Pending 时首先看调度器事件。它会列出每类节点被排除的原因，比逐个检查节点更高效。

kubectl describe pod <POD> -n <NS>
kubectl get events -n <NS> --sort-by=.lastTimestamp
kubectl get nodes -o custom-columns=NAME:.metadata.name,TAINTS:.spec.taints

常见原因

资源 request 超过任何单节点可用量
nodeSelector 或亲和性条件没有匹配节点
节点存在未容忍的 taint
PVC 尚未绑定或受可用区限制
hostPort、拓扑分布约束或 PDB 间接阻塞调度

kubectl top node 不是调度依据。调度器使用 request 和 allocatable，因此节点实际利用率低也可能无法调度。

验证资源碎片

kubectl describe nodes | grep -A8 'Allocated resources'
kubectl get pod -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,CPU:.spec.containers[*].resources.requests.cpu,MEM:.spec.containers[*].resources.requests.memory

修复原则

优先修正不合理 request 和约束，再考虑扩容。不要为了让单个 Pod 落地而移除全局安全 taint。修复后确认调度耗时、扩容器事件和工作负载副本分布。