How the scheduler places pods
Filter then score: how a pod is assigned a node.
In plain terms
The scheduler is a host seating diners. First it crosses off tables that can’t fit the party (filter), then picks the best table that’s left (score). If no table fits, the party waits at the door — that’s a Pending pod.
When you create a pod it starts with no node assigned. The scheduler watches for these unscheduled pods and, for each, runs two phases — filter, then score — to pick the best node and bind the pod to it. Everything else in this section is a way to influence those two phases.
If filtering leaves zero nodes, the pod stays Pending — and kubectl describe pod prints exactly which predicate rejected each node.
Filtering (predicates) removes nodes that cannot run the pod: not enough CPU or memory, an unsatisfied nodeSelector, or a taint with no matching toleration. Scoring (priorities) then ranks the survivors — spreading load, honoring affinity — and the highest score wins the binding.
Pending is a scheduling verdict
A Pending pod has not been placed anywhere. Read its Events — “Insufficient cpu” or “node(s) had untolerated taint” is printed there, and it tells you which lever to pull.