2.6 Kubernetes Scheduler Architecture

Kubernetes Scheduler Architecture is the specific internal structure of the scheduler as a pipeline of extension points, describing how an unscheduled Pod moves through distinct, ordered stages, from filtering through binding, and how each stage is architected to accept pluggable plugins rather than hardcoded logic.

Scheduling Framework as a Pipeline of Extension Points

Ordered Stages, Each with a Defined Role

The scheduler is architected as a sequence of well-defined stages: queuing, filtering, scoring, reserving, permitting, and binding, each responsible for a narrow part of the overall decision, with a Pod flowing through them in a fixed order for every scheduling attempt.

Plugins as the Unit of Extension

Rather than embedding all scheduling logic directly, each stage is architected to invoke a configurable set of plugins, meaning the specific criteria used for filtering or scoring nodes are determined by which plugins are enabled at that particular stage rather than by logic fixed inside the scheduler's core loop.

Queuing and Filtering Architecture

An Internal Priority Queue

Unscheduled Pods are architected to enter an internal scheduling queue, ordered by priority, from which the scheduler pulls the next Pod to attempt to schedule, ensuring higher-priority Pods are considered before lower-priority ones when contention exists.

Filtering as a Fast Elimination Pass

The filtering stage is architected to run relatively cheap, elimination-oriented checks across all nodes first, quickly discarding any node that cannot possibly satisfy the Pod's hard requirements before the more expensive scoring stage is invoked on the remaining candidates.

Scoring and Binding Architecture

Weighted Aggregation Across Scoring Plugins

The scoring stage is architected to invoke every enabled scoring plugin against each remaining feasible node, combining their individual weighted outputs into a single aggregate score used to rank and select the final node.

Binding as the Final, Committing Stage

Binding is architected as the last stage in the pipeline, the point at which the scheduler's decision is written back to the API server as a durable binding between the Pod and the selected node, after which the scheduler's responsibility for that Pod ends.

Concurrency and Consistency Architecture

Cache-Based View of Cluster State

To avoid querying the API server for every individual scheduling decision, the scheduler is architected around an internal cache reflecting current node and Pod state, kept up to date through the same watch mechanism used elsewhere in the control plane.

Assume-and-Reconcile for In-Flight Decisions

Because binding a Pod does not happen instantaneously, the scheduler is architected to optimistically assume a Pod has been placed on a node immediately after making that decision, updating its internal cache before the binding is even confirmed, and reconciling any discrepancy if the assumption later proves incorrect.

Scheduler Pipeline Diagram