事件定位
FailedScheduling 是调度器放弃为 Pod 选节点时写下的事件，典型原文是 0/N nodes are available 后面跟随一串排除理由。适用平台是 Kubernetes。它最大的价值在于已经把「哪些节点、因为什么被排除」列清楚了，读这条事件比猜测快得多：常见的排除项包括资源不足、节点亲和不匹配、污点未容忍、卷拓扑冲突、端口或拓扑分布限制。
基本信息
| 触发时机 | 调度器一轮调度结束后仍无可用节点，Pod 停在 Pending |
|---|---|
| 事件位置 | kubectl describe pod 的 Events，或 kubectl get events 按 reason 过滤 |
| 信息结构 | 可用节点数与各原因被排除的节点数并列出现 |
| 自动重试 | 调度器会在集群状态变化时重试，事件会重复出现 |
典型使用场景
- 扩容后新副本起不来：确认是集群容量问题还是约束条件写死
- 节点打标签或改 taint 之后故障：核对节点侧变更与 Pod 的约束是否还匹配
- 有状态服务迁移卡住：本地卷或可用区拓扑限制了可用节点
- 配额与准入排查：区分是调度失败还是创建阶段被配额拒绝
- 巡检自动化：按 reason 过滤事件，把长时间 Pending 的 Pod 捞出来告警
读事件
读事件
kubectl describe pod pending-x | sed -n '/Events:/,$p' # 事件原文与排除明细
kubectl get events --field-selector reason=FailedScheduling --sort-by=.lastTimestamp | tail -5
kubectl describe node node-1 | grep -A5 'Allocated resources' # 节点剩余 requests
kubectl get node node-1 -o jsonpath='{.spec.taints}' # 节点污点
kubectl get pod pending-x -o jsonpath='{.spec.nodeSelector}' # Pod 的约束条件事件片段（示例）
事件片段（示例）
0/3 nodes are available: 1 node(s) had untolerated taint {dedicated: gpu},
2 Insufficient memory, 1 node(s) didn't match Pod's node affinity/selector.常见排除原因
| 事件里的措辞 | 含义 | 处理方向 |
|---|---|---|
| Insufficient cpu/memory | 节点剩余 requests 不足 | 降 requests、扩节点或腾挪负载 |
| didn't match Pod's node affinity/selector | 标签约束不匹配 | 核对节点标签与 nodeSelector |
| untolerated taint | 污点未容忍 | 补 tolerations 或清污点 |
| node(s) had volume node affinity conflict | 卷的可用区与节点不一致 | 把 Pod 调度到卷所在可用区 |
| didn't match pod anti-affinity rules | 反亲和与现有副本冲突 | 放宽为软约束或扩拓扑域 |
同一句里各类原因并列出现，先修出现次数较多的那类，往往能立刻放行；只改一个条件后重新 describe，看排除数量是否下降。
调度器只在集群状态变化时重试，删掉 Pod 重建会得到一条全新的事件，比等下一次重试更直观。