Kubernetes Node Pod Admission

Kubernetes Node Pod Admission is the process by which a node's kubelet decides whether a Pod that has been assigned to it may actually be started on that node, acting as a final, node-local checkpoint that runs after the scheduler has already bound the Pod but before any of its containers are created. This distinction matters because scheduling and admission are deliberately separate concerns in Kubernetes: the scheduler makes a cluster-wide placement decision based on the state it had visibility into at decision time, while the kubelet re-validates that decision locally, using the most current information available on the node itself, and rejects the Pod if conditions have changed or if node-level constraints would be violated.

Why Node-Level Admission Exists

Scheduler-Kubelet Decoupling

The scheduler and kubelet operate asynchronously and do not share a transaction: the scheduler commits a binding decision to the API server, and the kubelet later observes that binding through its watch on Pods assigned to its node. Because time elapses between these two steps, and because the scheduler's view of the node may already be stale by the time the kubelet acts, the kubelet performs its own admission checks rather than blindly trusting the scheduler's decision.

Defense Against Race Conditions

Multiple Pods can be scheduled to the same node in close succession, and if several scheduling decisions are made against a similar snapshot of available resources, the sum of those decisions can locally overcommit the node once they all arrive. Node Pod Admission is what catches this after the fact, on the node where the actual resource pressure would occur.

The Admission Pipeline

Ordering of Checks

When the kubelet's SyncLoop observes a new Pod assigned to its node, it runs the Pod through a sequence of PodAdmitHandler implementations before proceeding to create the PodSandbox and containers. Each handler returns either an admission decision to allow the Pod or a rejection with a reason, and any single rejection prevents the Pod from being admitted.

Built-In Admission Handlers

The kubelet includes several built-in handlers evaluated during this pipeline: an evictionAdmitHandler that refuses new Pods while the node is already experiencing resource pressure that led to prior evictions, a sysctl handler that validates any Pod-level sysctl settings against what the node allows, and a topology manager handler that verifies the Pod's resource requests can be satisfied within a consistent NUMA topology alignment when topology-aware scheduling is enabled.

Resource Fit Re-Verification

Independent of the pluggable handler framework, the kubelet re-checks that the Pod's aggregate resource requests still fit within the node's allocatable capacity, accounting for all other Pods already running or already admitted on that node, since the scheduler's cached view of allocatable resources can diverge from the kubelet's real-time accounting.

Rejection and Its Consequences

Pod Status on Rejection

When a Pod fails node-level admission, the kubelet does not attempt to start any of its containers. Instead, it sets the Pod's phase to Failed and records a reason and message describing which check rejected it, and these fields are visible to users inspecting the Pod's status or events.

No Automatic Rescheduling by the kubelet

The kubelet itself does not reschedule a rejected Pod to a different node; if the Pod belongs to a controller such as a ReplicaSet or Deployment, the controller observes the failed Pod and creates a replacement, which the scheduler then places again, potentially on a different node with sufficient capacity.

Static Pods and Admission

Static Pods, which the kubelet manages directly from local manifest files rather than through the API server, go through the same PodAdmitHandler pipeline as any other Pod, meaning even statically defined workloads can be rejected locally if they violate eviction, sysctl, or topology constraints.

Relationship to Other Admission Concepts

Distinction from API Server Admission Control

Node Pod Admission should not be confused with API server admission control, which includes admission webhooks, validating and mutating controllers, and policies such as Pod Security Admission; those mechanisms run centrally at the API server before a Pod object is even persisted, whereas Node Pod Admission runs entirely on the node, after persistence and scheduling, as a final local gate.

Interaction with Node Conditions

Node conditions such as MemoryPressure, DiskPressure, and PIDPressure, maintained by the kubelet's eviction manager, directly influence the outcome of node-level admission, since the evictionAdmitHandler consults these conditions to decide whether best-effort Pods in particular should be allowed onto an already-constrained node.