Kubernetes Pod Node Handoff

Kubernetes Pod Node Handoff is the transition point at which responsibility for a Pod passes from the scheduler, which decided where the Pod should run, to the kubelet on the chosen node, which is responsible for actually running it. This handoff is mediated entirely through the API server: the scheduler and kubelet never communicate directly, and the Pod object itself is the shared state both sides observe and act upon.

The Binding Event

How the Scheduler Signals a Decision

The scheduler communicates its placement decision by creating a Binding object referencing the Pod, which the API server applies by setting spec.nodeName on the Pod resource. This single field write is the entire mechanism of handoff; there is no separate handshake or acknowledgment protocol between scheduler and kubelet.

kubectl get pod node-handoff-example -o jsonpath='{.spec.nodeName}'

Immutability After Binding

Once spec.nodeName is set, it cannot be changed. If the assigned node turns out to be unsuitable after the fact, for example due to a race condition on resource availability, the correct recovery is deleting and recreating the Pod, not reassigning it to a different node.

Kubelet-Side Observation

Watching for Assigned Pods

Each kubelet runs a watch against the API server filtered to Pods where spec.nodeName matches its own node identity. The moment a Binding sets that field, the relevant kubelet observes the new Pod in its watch stream and begins local admission handling.

Kubelet Admission Re-Check

Because cluster state can shift in the interval between the scheduler's scoring decision and the kubelet's observation of the bound Pod, the kubelet performs its own local admission check, verifying that the Pod's declared resource requests still fit within the node's current allocatable capacity before proceeding.

status:
  phase: Pending
  conditions:
    - type: PodScheduled
      status: "True"

At this point the Pod's PodScheduled condition is true, but Initialized, ContainersReady, and Ready remain false until the kubelet completes its own portion of the lifecycle.

What the Handoff Does Not Include

No Guarantee of Success

Binding a Pod to a node is a statement of intent, not a guarantee of successful execution. If the kubelet's local admission check fails, or if the node cannot pull the required images, the Pod remains stuck in Pending on that node; the scheduler does not automatically retry placement elsewhere, since from its perspective the Pod is already scheduled.

No Data Transfer

The handoff transfers only the placement decision, not any application state. Any volumes, secrets, or ConfigMaps the Pod requires are fetched independently by the kubelet after handoff, using the references already present in the Pod's spec.

Failure Modes After Handoff

Node Failure Post-Binding

If the assigned node becomes unreachable after a Pod is bound but before it starts running, the Pod's containers never transition out of Waiting. Detection relies on node heartbeat timeouts, after which the node controller marks the node NotReady and, if the condition persists past the configured toleration, the Pod becomes eligible for eviction and, if owned by a controller, replacement on a different node.

tolerations:
  - key: "node.kubernetes.io/not-ready"
    operator: "Exists"
    effect: "NoExecute"
    tolerationSeconds: 300

Node Handoff Diagram

This indirect, API-mediated handoff keeps the scheduler and kubelet fully decoupled: either can restart, fall behind, or be replaced without the other needing direct awareness of it, since the Pod object in the API server is the single source of truth both consult.