Skip to main content
In this lesson we cover the Kubernetes scheduler — the component that decides which node a Pod should run on. The Kubernetes scheduler (kube-scheduler) is responsible for selecting the best node to host each unscheduled Pod. It only makes the placement decision; it does not create or start containers on the node. The kubelet on the chosen node is responsible for instantiating the Pod and interacting with the container runtime to start containers.
The scheduler selects the node for a Pod; the kubelet on that node instantiates the Pod and manages its containers.
An infographic of Kubernetes architecture. The left shows master components (Controller Manager, etcd cluster, kube-scheduler) and the right shows worker nodes depicted as ships carrying multiple containers.
Why you need a scheduler When you run many nodes and many Pods, an automated scheduler is essential to ensure Pods land on appropriate nodes that satisfy constraints, balance load, and respect placement policies. The scheduler prevents resource exhaustion and enforces placement rules so applications run reliably. How the scheduler assigns Pods The kube-scheduler evaluates each unscheduled Pod and selects a node using two primary phases:
  • Filtering (predicate phase): remove nodes that cannot satisfy the Pod’s hard requirements — insufficient CPU/memory, failing nodeSelector or nodeAffinity, mismatched taints/tolerations, or unsatisfied topology constraints.
  • Scoring (prioritization phase): score the remaining candidate nodes using priority functions to pick the best fit — e.g., spreading Pods evenly, preferring nodes with more spare capacity, honoring soft affinity/anti-affinity, or optimizing for data locality.
A dark-themed diagram titled "kube-scheduler" showing the scheduling steps ("1. Filter Nodes", "2. Rank Nodes") with a pod labeled "CPU:10" and stylized node/server icons indicating capacities (4, 12, 16).
Detailed example
  • Suppose a Pod requests 10 CPUs:
    • Filtering removes nodes that cannot supply 10 CPUs.
    • For each remaining node the scheduler computes the post-placement free CPU. A node that would have 6 CPUs free after placement scores higher than one that would have only 2 CPUs free.
  • The scheduler aggregates scores from multiple priority functions, normalizes them, and selects the node with the highest overall score.
  • After selecting a node, the scheduler issues a binding API call to make the Pod scheduled to the chosen node. The kubelet on that node then creates and runs the Pod.
High-level scheduler workflow
  1. Filter out nodes that cannot satisfy the Pod’s hard constraints (resource requests, taints, nodeSelectors, nodeAffinity, etc.).
  2. Score the remaining nodes using priority/scoring functions (spreading, resource balancing, affinity, etc.).
  3. Choose the node with the highest score and bind the Pod to that node (scheduler issues the binding; kubelet on the node creates the Pod).
Extending and customizing scheduling
  • You can configure the kube-scheduler via a config file to tune existing plugins or enable/disable scheduling behaviors.
  • It is possible to run a custom scheduler (a different process) and select it in a Pod spec with spec.schedulerName.
  • Scheduling is influenced by numerous other features: resource requests and limits, taints and tolerations, nodeSelector, nodeAffinity and podAffinity/podAntiAffinity. Understanding these features helps control placement precisely.
Installing and inspecting the kube-scheduler If you run a kube-scheduler outside kubeadm (for example on a custom control plane), download the kube-scheduler binary from the Kubernetes release page and run it as a system service. Example binary download:
Example systemd ExecStart snippet:
kubeadm and static Pod deployment When you use kubeadm, kube-scheduler is typically deployed as a static Pod on the control-plane node(s) and runs in the kube-system namespace. The static Pod manifest lives at /etc/kubernetes/manifests/kube-scheduler.yaml. Example fragment:
Commands to inspect the kube-scheduler on a control-plane node:
  • View the static Pod manifest:
  • Check the running process and its arguments:
    Or use pgrep, pidof, ps -ef, etc., to locate the process and inspect command-line options.
Useful links and references Well, that’s it for this lesson.

Watch Video