What is the role of the kube-scheduler and how does pod scheduling work?
Learn what the Kubernetes kube-scheduler does and how pod scheduling works through filtering and scoring, with taints, affinity, and resource requests.
Expected Interview Answer
The kube-scheduler is the control-plane component that watches for newly created pods with no assigned node and selects the best node for each one to run on. It does not start the pod itself; it only decides placement by writing the chosen node name into the pod's spec.
Scheduling happens in two phases: filtering, where nodes that cannot run the pod are eliminated (insufficient CPU/memory, failing node selectors, taints without tolerations, unmet affinity rules), and scoring, where the surviving feasible nodes are ranked to pick the best fit. Once a node is chosen, the scheduler performs a binding that sets pod.spec.nodeName, and the kubelet on that node then pulls images and starts the containers. Constraints like nodeSelector, node/pod affinity and anti-affinity, taints and tolerations, and resource requests all steer the decision.
- Automatic, balanced placement across the cluster
- Respects resource requests so nodes are not overcommitted
- Honors affinity, anti-affinity, taints and tolerations
- Enables spreading for high availability
- Pluggable and extensible via the scheduling framework
AI Mentor Explanation
The kube-scheduler is the captain deciding which fielder covers each position for the next ball. He first rules out players who cannot fill a slot — a bowler mid-over cannot field at slip — then ranks the eligible ones by form, fitness, and who is best placed, before finally sending each to a spot. He only assigns positions; the players themselves do the catching.
Step-by-Step Explanation
Step 1
Detect unscheduled pods
The scheduler watches the API server for pods whose spec.nodeName is empty.
Step 2
Filter (predicates)
Eliminate nodes that cannot run the pod: not enough CPU/memory, failing nodeSelector or affinity, taints with no matching toleration.
Step 3
Score (priorities)
Rank the remaining feasible nodes using scoring plugins such as least-requested resources, balanced allocation, and affinity preferences.
Step 4
Select and bind
Pick the highest-scoring node and create a binding that sets pod.spec.nodeName to that node.
Step 5
Kubelet takes over
The kubelet on the chosen node sees the assignment, pulls images, and starts the containers.
What Interviewer Expects
- Clear separation of scheduling (decision) from running (kubelet)
- Knowledge of the filter then score two-phase model
- Awareness of resource requests versus limits in scheduling
- Understanding of taints, tolerations, and affinity
- Mention of the pluggable scheduling framework
Common Mistakes
- Saying the scheduler starts or runs the containers
- Confusing resource requests (used for scheduling) with limits
- Ignoring taints and tolerations when explaining placement
- Believing the scheduler load-balances at runtime rather than at placement time
- Forgetting that a pod with no feasible node stays Pending
Best Answer (HR Friendly)
“The kube-scheduler is the part of Kubernetes that decides which machine each new workload should run on. It rules out machines that cannot fit the job, then picks the best remaining one, and the node itself does the actual work of starting the containers.”
Code Example
apiVersion: v1
kind: Pod
metadata:
name: web
spec:
nodeSelector:
disktype: ssd
tolerations:
- key: "dedicated"
operator: "Equal"
value: "web"
effect: "NoSchedule"
containers:
- name: web
image: nginx:1.27
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"Follow-up Questions
- How do taints and tolerations differ from node affinity?
- What happens to a pod when no node passes the filtering phase?
- How would you run multiple schedulers in one cluster?
- How do resource requests influence scheduling decisions?
- What is pod topology spread and why use it?
MCQ Practice
1. What does the kube-scheduler actually do when it schedules a pod?
The scheduler only decides placement by binding the pod (setting nodeName); the kubelet then pulls images and starts containers.
2. Which value does the scheduler primarily use to decide if a node has room for a pod?
Scheduling is based on requests, which reserve capacity; limits cap runtime usage and are not the scheduling basis.
3. In which order does the scheduler evaluate nodes?
The scheduler first filters out infeasible nodes, then scores the survivors to pick the best one.
Flash Cards
What is the kube-scheduler's job? — Watch for unscheduled pods and choose the best node for each by binding pod.spec.nodeName.
The two scheduling phases — Filtering (eliminate infeasible nodes) then scoring (rank feasible nodes).
Requests vs limits for scheduling — The scheduler uses requests to reserve capacity; limits only cap runtime usage.
Who starts the containers? — The kubelet on the selected node, not the scheduler.
Pod with no feasible node? — It stays in Pending state until a suitable node appears.