9.3 Kubernetes Pod Scheduling Lifecycle

Kubernetes Pod Scheduling Lifecycle is the specific segment of a Pod's overall existence that spans from the moment it is created without a node assignment to the moment the scheduler successfully binds it to a node. This lifecycle segment is entirely governed by the scheduler's internal processing loop and represents the phase during which a Pod is visible to the cluster but not yet running anywhere.

Entering the Scheduling Queue

Unscheduled Pod Detection

The scheduler watches the API server for Pods whose spec.nodeName field is empty, which signals that they require a scheduling decision. Upon detecting such a Pod, the scheduler adds it to an internal priority queue, ordered in part by the Pod's priorityClassName value, so that higher-priority Pods are considered for scheduling ahead of lower-priority ones.

Queue Backoff and Retry

If a Pod cannot be scheduled during an attempt, it is placed into a backing-off queue rather than being retried immediately, with the retry interval increasing over successive failed attempts. This prevents a single unschedulable Pod from being repeatedly retried in a tight loop and consuming scheduler resources at the expense of other pending Pods.

Filtering Phase

Predicate Evaluation

For each Pod being scheduled, the scheduler evaluates every node in the cluster against a set of filtering predicates, eliminating nodes that lack sufficient allocatable resources, do not satisfy required node affinity rules, are tainted without a matching toleration on the Pod, or otherwise fail to meet a hard constraint declared in the Pod specification.

Empty Feasible Node Set

If no nodes remain after filtering, the Pod remains unscheduled and stays in the Pending phase, with the scheduler periodically re-evaluating it as cluster conditions change, such as when a node's resource usage decreases or a new node joins the cluster.

Scoring Phase

Ranking Feasible Nodes

Nodes that survive filtering are then scored using a set of scoring plugins that evaluate factors such as how evenly resource usage would be balanced across the cluster, whether preferred node or Pod affinity rules are satisfied, and how closely the placement aligns with topology spread constraints declared by the Pod.

Selecting the Highest-Scoring Node

The scheduler sums the weighted scores from each plugin and selects the node with the highest aggregate score. In the event of a tie, the scheduler selects among the tied candidates, ensuring a deterministic yet load-balanced distribution of Pods across the cluster over time.

Binding Phase

Binding Request

Once a node is selected, the scheduler does not directly instruct the node to run the Pod; instead, it issues a binding request to the API server, which updates the Pod object's nodeName field. This indirection ensures that the scheduling decision is recorded centrally and can be observed by any component watching Pod objects.

Handling Binding Failures

If the binding operation fails, for instance due to a conflict with another update to the same Pod, the scheduler releases its tentative assumption about that node's resource consumption and returns the Pod to the scheduling queue for reconsideration, ensuring resource accounting remains accurate.

Preemption Within the Scheduling Lifecycle

Triggering Preemption

When a Pod cannot be scheduled due to resource contention, the scheduler may attempt preemption, identifying lower-priority Pods on a node whose removal would allow the pending Pod to fit, and evicting them to free up capacity, provided the pending Pod's priority is high enough to justify displacing them.

Nominated Node Tracking

During preemption, the scheduler records a nominatedNodeName on the pending Pod, signaling its intended target node even before the lower-priority Pods have finished terminating, which helps prevent the scheduler from repeatedly selecting the same node for competing preemption attempts.

Transition Out of the Scheduling Lifecycle

Handoff to the Kubelet

Once binding succeeds, responsibility for the Pod passes from the scheduler to the kubelet on the assigned node, marking the formal end of the scheduling lifecycle segment and the beginning of the node-local creation and initialization process that brings the Pod's containers into a running state.