4.5 Kubernetes Node Pod Admission

Kubernetes Node Pod Admission is the process by which a node's kubelet decides whether a pod assigned to it by the scheduler can actually be accepted and started, applying a series of local checks that run independently of the scheduler's own placement decision. It acts as a final gate on the node itself, verifying that resources, constraints, and policies are satisfied before any container creation begins, and it can reject a pod even after the API server has already bound it to that node.

Why Node-Level Admission Exists

The Gap Between Scheduling and Execution

The scheduler makes placement decisions based on a cached view of cluster state, which can become stale between the moment a decision is made and the moment the kubelet actually attempts to run the pod. Node Pod Admission exists to catch discrepancies introduced by this delay, such as resources consumed by other pods that started in the interim, or node conditions that changed after scheduling occurred.

Defense in Depth

Admission at the node level complements admission control at the API server. While API-server-side admission controllers validate and mutate pod specs before persistence, node-level admission re-validates feasibility at the point of actual execution, providing a second layer of protection against inconsistent or unsafe pod placement.

Core Admission Checks

Resource Fit Verification

The kubelet recomputes whether the sum of resource requests from all pods already running or admitted on the node, plus the incoming pod's requests, would exceed the node's allocatable capacity for CPU, memory, and ephemeral storage. If the pod would cause an overcommit beyond allocatable limits, it is rejected locally rather than being forced to run.

NodeAffinity and NodeSelector Re-check

Even though the scheduler filters nodes by affinity rules and node selectors, the kubelet independently re-evaluates these constraints against the current node labels at admission time, guarding against races where labels change between scheduling and binding.

Taints and Tolerations

The kubelet verifies that the pod tolerates any taints currently present on the node. If a taint with effect NoExecute or NoSchedule has been added to the node after the scheduling decision but before admission, and the pod lacks a matching toleration, admission fails.

Admission Handlers

Pluggable Handler Chain

Internally, the kubelet runs pod admission through a chain of handler functions, each of which can approve or reject the pod with a specific reason. This handler chain includes checks for resource availability, hostPort conflicts, node readiness, and volume constraints, evaluated in sequence before the pod is allowed to proceed toward sandbox creation.

hostPort Conflict Detection

If a pod requests a specific host port that is already claimed by another pod on the same node, the admission handler responsible for port allocation rejects the pod, preventing a runtime-level bind failure later in the container startup sequence.

Critical Pod Admission

Pods marked with a critical priority class receive special handling during admission under resource pressure, allowing the kubelet to admit them even when it would otherwise reject lower-priority pods, and potentially triggering preemption of existing lower-priority pods to make room.

Node Conditions and Readiness Gates

NotReady and Unschedulable States

A node reporting NotReady status, or marked unschedulable through cordoning, will generally not receive new pod bindings from the scheduler, but the kubelet's own admission logic also independently refuses to start new pods while the node itself is not in a healthy state, adding a redundant safety check.

Disk and Memory Pressure

If the node is under active disk pressure or memory pressure conditions, as tracked by the kubelet's eviction manager, incoming pod admission can be denied for new BestEffort or Burstable pods to avoid worsening resource contention while the node is already stressed.

Rejection Handling and Status Reporting

Pod Status on Rejection

When admission fails, the kubelet sets the pod's phase to Failed and populates the pod status with a reason and message describing which admission check failed, such as OutOfcpu, OutOfmemory, or NodeAffinity, giving operators and controllers visibility into why the pod never started.

Interaction with Controllers

For pods managed by higher-level controllers such as Deployments or ReplicaSets, an admission rejection at the node typically results in the controller observing the failed pod and creating a replacement, which is then rescheduled, potentially onto a different node with sufficient capacity.

Relationship to Static and Mirror Pods

Static Pods

Static pods, defined directly on the node through manifest files rather than through the API server, bypass scheduler-based binding entirely but still pass through the kubelet's node-level admission checks before being started, since the checks operate on the kubelet's local view of resource usage regardless of how a pod was assigned to the node.

Mirror Pod Representation

Once a static pod is admitted and running, the kubelet creates a corresponding mirror pod object in the API server so that the pod is visible through normal Kubernetes tooling, even though its admission decision was made entirely locally by the node rather than through the scheduler.