FailedScheduling 是什么
Pod 处于 Pending 且事件里出现 FailedScheduling，意味着调度器考察了所有节点后没有找到可用节点。事件的 message 会写明拒绝原因：资源不足、污点不容忍、亲和性不匹配、卷拓扑冲突、主机端口被占。它是排查调度的第一手材料，比盲改 Pod 参数高效得多。
基本信息
| 看事件 | kubectl describe pod <名称> 末尾 Events，或 get events -A |
|---|---|
| 资源判定 | 按单个节点的可分配余量计算，不看集群总量 |
| requests | 未设 requests 的 Pod 调度宽松，但会引起节点超卖 |
| 污点 | 节点 taint 需要 Pod tolerations 匹配才可被调度 |
| 卷拓扑 | 卷所在的可用区必须与节点可用区一致 |
事件关键词与处置
| 关键词 | 含义 | 处置 |
|---|---|---|
| insufficient cpu/memory | 所有节点余量都不够 | 加节点、调小 requests 或清掉占资源的 Pod |
| had untolerated taint | 节点有污点且 Pod 未容忍 | 加 tolerations 或改用无污点节点 |
| didn't match node affinity | 亲和性或节点选择器无匹配 | 核对节点 label 与 nodeSelector |
| volume node affinity conflict | 卷与节点不在同一可用区 | 换节点池，或重建卷 |
| HostPort 冲突 | 节点上该主机端口已被占用 | 改 hostPort 或放宽调度范围 |
排查命令
排查命令
kubectl describe pod web-1 | grep -A3 "FailedScheduling" # 直接读拒绝原因
kubectl get nodes -o custom-columns=NAME:.metadata.name,CPU:.status.allocatable.cpu
kubectl describe node node-1 | grep -E "Taints|Allocated" # 污点与实际分配
kubectl get pods -A -o wide --field-selector status.phase=Pending
kubectl describe node node-1 | grep -A20 "Non-terminated Pods"典型使用场景
- 大内存 Pod 起不来报 insufficient memory，需要确认是否真的没有单节点放得下
- 节点刚打过维护污点，新副本全部 Pending
- GPU 等特殊机型靠 nodeSelector 指定，标签写错导致无节点匹配
- 用云盘做 RWO 卷的 Pod 与盘不在同一可用区，调度器直接拒绝
集群看起来还有空闲却调度不上，多数是 requests 碎片化：调度按单节点余量而非集群总量判断，几个小 Pod 的 requests 一凑，就没有任何一个节点能满足大 Pod。
为了骗过调度把 requests 调小，会让节点内存超卖，压力上来后触发 OOM 甚至整机雪崩；正确做法是增加节点或降低真实用量。
节点自身不健康也会表现为无法调度：被 cordon 或处于 NotReady 的节点直接不参与打分，事件里出现 node(s) were unschedulable；用 kubectl get nodes 看 STATUS 与 SchedulingDisabled 标记即可确认，不必一直在资源维度上找原因。