How Kubernetes Scheduler Finds the Best Node for Your Pods

Abstract

From the founding of the CNCF to the rapid rise of Kubernetes over six years, the project outperformed competitors like Mesos and Swarm to dominate container orchestration. Its success stems from visionary leadership, healthy community culture, and positive feedback loops between community and enterprises.

The series "Kubernetes Scheduling System" (version 1.20+) aims to provide a systematic, in‑depth understanding of Kubernetes scheduling across five articles, starting with this introductory piece.

1. Scheduling Overview

Kubernetes control plane includes three main components: kube‑scheduler, kube‑apiserver, and kube‑controller‑manager. The kube‑scheduler is a core component responsible for assigning Pods to nodes by listening to the apiserver, querying unscheduled Pods, and applying scheduling policies to place Pods on optimal nodes, thereby improving efficiency and reducing resource waste.

The scheduler’s primary objectives are:

Fairness : Ensure each node has a chance to receive Pods.

Resource Efficiency : Maximize utilization of CPU, memory, and other resources.

Performance : Quickly schedule large numbers of Pods even as the cluster scales.

Flexibility : Allow custom scheduling algorithms and multiple schedulers to run in parallel.

2. Scheduling Process

The following diagram illustrates the end‑to‑end flow when creating a Pod.

1. User creates a Pod via the command line. 2. kube‑apiserver validates the request and writes the object to etcd. 3. kube‑apiserver returns the result to the user. 4. kube‑scheduler continuously watches node and Pod events. 5. The scheduler adds the Pod to the scheduling queue and starts a scheduling cycle. 6. The scheduler binds the Pod to the highest‑scoring node. 7. kube‑apiserver records the binding in etcd. 8. kubelet watches the assigned Pod, invokes the CRI to create it (covered in later articles). 9. kubelet updates Pod status and reports back to kube‑apiserver. 10. kube‑apiserver persists the final state.

a. Scheduling Cycle

The scheduler’s work consists of two stages: filtering and scoring.

Filtering : Input is the full set of nodes; output is the subset that satisfies pre‑selection criteria (e.g., sufficient resources, matching labels).

Scoring : Nodes that pass filtering are scored according to algorithms; the node with the highest score is selected. If multiple nodes have equal scores, the scheduler picks one arbitrarily.

Note: Previously called "predicate" and "priorities"; now referred to as filtering and scoring.

b. Scheduling Algorithms

Two ways to configure filtering and scoring:

<code>1. Scheduling Policies: configure Predicate (filter) and Priorities (score) via files or ConfigMaps.
2. Scheduling Profiles: the scheduler’s plug‑in architecture defines stages such as QueueSort, PreFilter, Filter, PreScore, Score, Reserve, Permit, PreBind, Bind, and PostBind, allowing custom behavior at each stage.</code>

Below is a brief overview of the Scheduling Policies approach.

1) Predicates (Pre‑selection)

Predicates filter out nodes that do not meet requirements such as resource availability or label matching. Cloud‑provider‑specific predicates like MaxEBSVolumeCountPred have been deprecated.

2) Priorities (Scoring)

Priorities assign scores to the filtered nodes; higher scores indicate more suitable nodes (e.g., more free resources, lower load).