DevOps · interactive
How Kubernetes schedules pods
Each pod declares how much CPU it needs. The scheduler filters out nodes that can't fit it (or that it isn't allowed on), scores the rest, and binds the pod to the best. Watch seven pods land on three 4-CPU nodes.
node-a1.5/4 CPU
node-b0/4 CPU
node-c0/4 CPU
taint: gpu
queue: api-1 → api-2 → worker-1 → web-1 → train-1 → web-2 → report
api-1 (1.5 CPU) fits on node-a and node-b. Scoring prefers the least-allocated: node-a.
Requests, not real usage
The scheduler packs by what pods request. Requests too high waste nodes; too low and nodes get overcommitted.
Set them from measured usage.
Filter: who can fit it?
Enough free CPU and memory, matching node selectors and affinity, and taints the pod tolerates.
Taints keep ordinary pods off special nodes.
Score: who fits best?
Spread load (least allocated), honour preferences, spread replicas across zones.
topologySpreadConstraints for HA.
Pending and fragmentation
Free capacity scattered across nodes can't host a pod that needs it in one place. kubectl describe pod shows why.
0/3 nodes are available: Insufficient cpu
In production
Tools and technologies
Every pod goes through the scheduler.
Not tied to one language — use these names when you search docs or design a system.