标准答案
- 先看 Pod events 中调度器拒绝原因，再核对 requests、nodeSelector、affinity、tolerations、拓扑约束和 namespace quota。
- 如果是 PVC 未绑定，要继续查 StorageClass、可用区、容量和访问模式。
- 如果节点资源看似足够，还要考虑碎片化、预留资源、DaemonSet 开销和扩容器是否能提供合适节点。
- 修复后确认 Pod 实际落点、资源分配和业务流量，不要只删除 Pod 期待调度器重试。
题目解析
调度器要同时满足 requests、nodeSelector/affinity、taint/toleration、拓扑分布、PVC 拓扑和 namespace quota。节点当前 free 不等于可分配容量，还要扣除系统和 DaemonSet 预留，并考虑资源碎片导致单个 Pod 找不到连续可满足的节点。
排查从 Pod events 的 FailedScheduling 原因开始，再检查调度约束、配额、PVC 和扩容器能力。删除 Pending Pod 通常只会重复同一个决策；降低 request 可能让应用在运行时更容易被抢占或 OOM，必须先确认真实资源需求。
常见误区
- 误区：只看节点总内存。改正：核对 allocatable、requests、预留、碎片、污点和拓扑约束。
- 误区：盲目删除 Pod 或降低 request。改正：先读 events 定位约束，再调整容量或明确修改调度规则。