Scheduler filtering and scoring phases

WHAT THIS TESTS This checks whether you understand scheduling as a two-stage pipeline and the difference between hard constraints and soft preferences.

A GOOD ANSWER COVERS The scheduler first filters: it evaluates every Node and discards those that cannot feasibly run the Pod. Filtering considers whether the Node has enough allocatable CPU and memory, whether it satisfies a required nodeSelector or requiredDuringScheduling node affinity, whether the Pod tolerates the Node's taints, and whether required volumes can be attached. This yields a set of feasible Nodes. Then it scores: each feasible Node is ranked by weighted priority functions, such as balancing resource utilization, honoring preferred node or pod affinity and anti-affinity, and spreading replicas across zones or nodes. The scheduler picks the highest-scoring Node and binds the Pod to it via the apiserver. Taints and tolerations and required affinity are hard filters that exclude Nodes, while preferred affinity and spreading influence scoring rather than exclusion.

COMMON WRONG ANSWERS Conflating filtering and scoring into one step. Thinking taints rank Nodes instead of excluding them. Treating preferred affinity as a hard requirement. Believing the scheduler starts the container itself.

LIKELY FOLLOW-UPS What is the difference between required and preferred affinity? How do taints and tolerations work? What happens if no Node passes filtering? How does pod anti-affinity spread replicas?

ONE CONCRETE EXAMPLE A Pod requests a GPU and tolerates the gpu taint. Filtering eliminates all Nodes without GPUs and any GPU Node whose taint the Pod does not tolerate, leaving three GPU Nodes. Scoring then prefers the Node with the least existing GPU load and one in a zone where no replica yet runs, so the scheduler binds the Pod there. If no Node had passed filtering, the Pod would stay Pending until capacity appears.