直接回答：Pending 说明调度器没给它找到节点或镜像未就绪。第一步 kubectl describe pod 看 events 的 FailedScheduling 信息，它会明说原因：Insufficient cpu/memory（资源不够）、node selector/affinity 无匹配节点、taint 未容忍、PVC 未绑定。没 events 说明调度器还没处理——查调度器本身或 Pod 卡在 Init 容器。
展开解析：原因展开与解法：资源不足——注意调度看 requests 而非实际用量，requests 虚高是集群利用率杀手；解法纵向降 requests 或横向加节点/开 cluster autoscaler，kubectl describe node 看 Allocated resources 找碎片化（大 Pod 塞不进分散余量）。亲和与选择器——nodeSelector 的 label 打错字、requiredDuringScheduling 硬约束太死，kubectl get nodes --show-labels 对照；反亲和常见坑：required 级别的 podAntiAffinity 让副本互相排斥挤不下。taint——节点打了 NoSchedule 污点（master 默认有），Pod 需要对应 toleration；节点异常（NotReady、维护 cordon）也会带污点。PVC——Pending 且无 FailedScheduling 而是 Waiting for PVC：查 pvc 状态，StorageClass 不存在、PV 容量不足、local PV 绑错节点都卡这里，storage provisioner 的日志是下一步。隐蔽原因：resourceQuota 配额满（events 报 exceeded quota）、LimitRange 注入的默认 requests 把 Pod 顶出可调度范围、Init 容器镜像拉不到（Pending 但问题在 ImagePull）。工具：kubectl get pod -o wide 看无 NODE 即未调度；scheduler 的 events 与 kubectl describe 是最快入口，别一上来翻 scheduler 日志。
追问方向：调度器的 filtering 与 scoring 两阶段各做什么？Pod topology spread 与亲和的差异？
（约 490 字）