How does the kube-scheduler decide which node a pod goes on?

The scheduler watches for pods with an empty nodeName. For each, phase one (filtering) discards any node that violates a hard constraint: not enough allocatable CPU/memory for the pod's requests, a nodeSelector/required affinity the node doesn't match, a taint the pod doesn't tolerate, unsatisfiable volume/topology requirements, or ports already in use. Phase two (scoring) ranks the remaining feasible nodes using plugins — spreading pods of the same Service across nodes/zones, honoring preferred affinity/anti-affinity, balancing resource utilization, and image locality (a node that already has the image scores higher). The pod is bound to the top-scoring node (ties broken randomly). It's extensible via the scheduling framework or a custom scheduler, and pod priority/preemption can evict lower-priority pods to make room for a higher-priority one. Key insight: requests drive filtering, so wrong requests wreck placement decisions.