Kubernetes Preemption Placement

Kubernetes Preemption Placement is the specific process the scheduler follows to select a node and a set of lower-priority Pods to evict when a pending, higher-priority Pod cannot otherwise be placed anywhere in the cluster. Where priority scheduling broadly covers how PriorityClass values influence queue ordering and unlock preemption as a possibility, preemption placement is the detailed mechanics of how the scheduler chooses which node to target and which specific victim Pods to evict on that node — a nontrivial search problem, since evicting too many Pods wastes disruption, and evicting the wrong Pods might not even free enough resources to actually fit the pending Pod.

Preemption placement only runs as a fallback: it is triggered exclusively when ordinary, non-disruptive scheduling has already failed to find any viable node for the pending Pod.

When Preemption Placement Runs

Trigger Condition

After a Pod fails the ordinary filtering phase on every node in the cluster, the scheduler checks whether the Pod has a sufficiently high priority to be eligible for preemption at all — Pods without a PriorityClass (or with a low one) that fail ordinary scheduling simply remain Pending, without any preemption attempt.

Simulated Filtering Without Lower-Priority Pods

For each node, the scheduler simulates removing every Pod with lower priority than the pending Pod and re-evaluates whether the pending Pod would fit on that hypothetically emptied node — this identifies which nodes are even theoretically viable preemption targets before committing to any actual eviction.

Selecting the Preemption Target Node

Minimizing Disruption

Among nodes where preemption would make the pending Pod fit, the scheduler prefers the node requiring eviction of the fewest and lowest-priority Pods, and among candidates tied on that measure, the node whose evicted Pods have collectively been running for the shortest total time — minimizing both the number of workloads disrupted and how much accumulated runtime is lost.

Respecting PodDisruptionBudget Where Possible

The scheduler prefers a node and victim set that does not violate any applicable PodDisruptionBudget, but will proceed with a PDB-violating eviction if no PDB-respecting option exists anywhere in the cluster — a higher-priority Pod's placement need ultimately outweighs strict PDB compliance in Kubernetes' preemption logic, though PDB compliance is still the default, preferred outcome whenever achievable.

Selecting Victim Pods on the Target Node

Minimal Sufficient Eviction Set

Once a target node is chosen, the scheduler computes the smallest set of lower-priority Pods on that node whose removal frees enough resources for the pending Pod to fit — it does not evict every lower-priority Pod on the node indiscriminately, only as many as are actually necessary.

Priority-Ordered Victim Selection

Among lower-priority Pods on the target node, those with the lowest priority are preferred as eviction victims first, so that if a choice exists between evicting one medium-priority Pod versus several very-low-priority Pods to free the same amount of resources, the scheduler favors preserving the relatively higher-priority (even if still lower than the pending Pod) workloads where possible.

What Happens to Evicted Pods

Graceful Termination

Evicted Pods are terminated following their normal graceful termination process (respecting terminationGracePeriodSeconds), not abruptly killed — preemption triggers a standard Pod deletion, giving the evicted workload the same opportunity to shut down cleanly as any other deletion would.

Re-Entering the Scheduling Queue

Evicted Pods, if managed by a controller expecting a certain replica count (a Deployment's ReplicaSet, for instance), are typically recreated by that controller and re-enter the scheduling queue themselves, competing for placement on whatever capacity remains available afterward — preemption resolves the immediate pending Pod's placement, but does not guarantee the evicted workload's Pod is ever successfully rescheduled if cluster capacity remains generally tight.

Nomination and the Preemption Waiting Period

nominatedNodeName

Once the scheduler decides on a preemption target, it sets .status.nominatedNodeName on the pending Pod, recording the intended target node even before eviction has actually completed — this is visible information useful for understanding an in-progress preemption, though the Pod is not actually bound to that node until the victims have fully terminated and the fit is re-confirmed.

kubectl get pod codartium-high-priority-app -o jsonpath='{.status.nominatedNodeName}'

Observing Preemption

kubectl get events --field-selector reason=Preempted --sort-by=.lastTimestamp
kubectl describe pod codartium-high-priority-app

The Preempted event on victim Pods and a corresponding Scheduled event on the preempting Pod together tell the complete story of a preemption episode, which is the standard way to confirm preemption behaved as expected after the fact.

Example

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: codartium-urgent
value: 100000
---
apiVersion: v1
kind: Pod
metadata:
  name: codartium-preemption-example
spec:
  priorityClassName: codartium-urgent
  containers:
    - name: app
      image: codartium/urgent-app:latest
      resources:
        requests:
          cpu: "2"
          memory: "2Gi"