第一步永远是 kubectl describe pod 看 Events，调度器会把拒绝原因写得明明白白。原因一资源不足：0/3 nodes are available: 3 Insufficient cpu——集群可分配资源不够，注意是可分配（allocatable）不是物理总量，其他 Pod 的 requests 已经把额度占了。解法：调小 requests（很多应用 requests 拍脑袋给大了）、加节点、或者用 kubectl describe nodes 看各节点余量确认碎片化情况。
原因二亲和/反亲和：node affinity 要求的标签没有节点满足，pod anti-affinity 排斥的 Pod 占满了所有候选节点。原因三污点：节点带 NoSchedule 污点（GPU 节点、专用节点常见）而 Pod 没有对应 toleration。原因四存储：PVC 一直 Pending 拖着 Pod，describe pvc 看是 StorageClass 不存在、容量无库存（云盘配额）还是可用区不匹配—— WaitForFirstConsumer 模式的 PVC 要等 Pod 调度才绑，注意别和节点可用区标签打架。
原因五配额：namespace 的 ResourceQuota 用满，Events 里直接写 exceeded quota。原因六比较隐蔽：镜像拉取策略和节点选择互相矛盾（私有镜像的 pull secret 只配在部分 namespace）。排查心法：Pending 阶段容器根本没创建，别去翻容器日志（没有日志可翻），一切信息都在 Events 和调度器逻辑里；kubectl get events --sort-by=.lastTimestamp 看全 namespace 的事件流，往往能看到同一批 Pod 一起 Pending 的共性原因。