Kubernetes Pod Scheduling Lifecycle

Kubernetes Pod Scheduling Lifecycle is the specific segment of a Pod's overall existence during which the scheduler is responsible for it, beginning the moment a Pod is created without an assigned node and ending the moment a binding decision is committed. This lifecycle segment operates as a distinct control loop from Pod creation or Pod health, focused entirely on the question of node placement.

Entering the Scheduling Queue

Unscheduled Pod Detection

The scheduler watches the API server for Pod objects with an empty spec.nodeName. Any such Pod is placed into an internal scheduling queue, ordered by priority, with higher priorityClassName values processed ahead of lower ones.

apiVersion: v1
kind: Pod
metadata:
  name: scheduling-lifecycle-example
spec:
  priorityClassName: high-priority
  containers:
    - name: app
      image: registry.example.com/app:1.0.0

Backoff for Repeated Failures

If a Pod cannot be scheduled on a given attempt, it is moved to a backoff queue rather than retried immediately, with the retry interval increasing after repeated failures to avoid the scheduler spending excessive cycles on a Pod that consistently cannot be placed.

The Filtering Phase

Predicate Evaluation

For each Pod at the front of the queue, the scheduler evaluates every node in the cluster against a set of filter plugins, discarding nodes that fail any hard requirement: insufficient allocatable CPU or memory, unmatched nodeSelector or required node affinity, unmet pod affinity or anti-affinity rules, or an untolerated taint.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: node.kubernetes.io/instance-type
                operator: In
                values:
                  - compute-optimized

The Scoring Phase

Ranking Feasible Nodes

Nodes surviving the filter phase are scored by scoring plugins that account for factors such as resource balance across the node, image locality (whether the node already has the required image cached), and preferred affinity terms. Each plugin returns a normalized score, which is combined into a final weighted total per node.

Selecting the Winner

The node with the highest aggregate score is selected. Ties are broken pseudo-randomly to avoid concentrating load on a single node when multiple candidates are equally suitable.

Binding

Committing the Decision

The scheduler creates a Binding subresource for the Pod, which the API server uses to set spec.nodeName. This is an atomic, optimistic operation: if the target node's available capacity changed between scoring and binding, the bind can fail, and the scheduler returns the Pod to the queue for re-evaluation.

kubectl get pod scheduling-lifecycle-example -o jsonpath='{.spec.nodeName}'

Preemption as a Lifecycle Extension

When No Node Fits

If no node passes the filter phase for a Pod, but the Pod carries a higher priority than Pods running on some node, the scheduler may evaluate preemption: selecting victim Pods to evict so that their freed capacity allows the pending Pod to be scheduled. This extends the scheduling lifecycle to include a nomination phase, where the pending Pod is marked with a nominated node while eviction of the victims proceeds asynchronously.

Scheduling Lifecycle Diagram

Once binding succeeds, the Pod's scheduling lifecycle is complete, and responsibility for the Pod transfers entirely to the kubelet on the assigned node, which begins the separate sandbox and container startup sequence.