Scheduler & Controllers

How a Pod Gets a Node

A pod with no spec.nodeName waits in the scheduling queue. The leader-elected scheduler processes it in two phases:

1. Filtering — discard nodes that break hard constraints: insufficient resources.requests cpu or memory, node condition pressure or unschedulable taints, selector/affinity mismatches, taints without a matching toleration.
2. Scoring — rank survivors using heuristics like PodTopologySpread, NodeResourcesFit, and image locality.

The winner is written into spec.nodeName, which ends scheduling for that pod's lifetime. Scheduling is edge-triggered: when capacity frees or a node appears, queued pods are reconsidered rather than the whole cluster being re-scored.

Influencing Placement

Three levers, from softest to hardest:

nodeSelector:
  disktype: ssd
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - { key: topology.kubernetes.io/zone, operator: NotIn, values: [zone-a] }
tolerations:
- { key: dedicated, operator: Equal, value: batch, effect: NoSchedule }

Reserve capacity with resources.requests — a pod asking cpu: 2 cannot land where allocatable is 1.5. Soft preferences use preferredDuringSchedulingIgnoredDuringExecution with weights when you want a nudge, not a rule.

Pending Pods and Controller Loops

Pitfall 1 — reading Pending without events. kubectl describe pod shows the scheduler's exact verdict: "0/3 nodes are available: 3 Insufficient cpu." Fix requests, add capacity, or relax constraints — hand-setting nodeName bypasses the scheduler entirely and breaks future rescheduling.

Pitfall 2 — blaming the scheduler for controller work. Replication, rollouts, and node lifecycle belong to controller-manager loops watching the API; the scheduler only binds pods once.

Interview-ready: explain filter, score, bind, then a scenario — a pod stuck Pending after autoscaling usually means label or taint mismatch, not missing nodes. Mention leader election and that scheduler decisions appear as Events on the pod.