Preempted: A higher-priority pod needed the space and this pod was removed to make room

Preemption evicts lower-priority pods so a higher-priority pending pod can be scheduled. The evicted pod did nothing wrong — it was outbid.

Applies to: All Kubernetes versions with pod priority enabled

What it means

When a pod cannot be scheduled, the scheduler may look for a node where evicting one or more lower-priority pods would let it fit. If it finds one, those pods are marked for deletion and the pending pod is scheduled in their place. The mechanism is driven by PriorityClasses, and it exists so that critical workloads are not blocked by less important ones during a capacity shortage. The consequence to understand is that a workload with no priority class set gets the default priority of zero and can be preempted by anything with a higher one — which, on a cluster where someone has defined a high-priority class for batch work, may not be what anyone intended.

Most common causes

• A higher-priority pod could not be scheduled and preemption freed space for it.
• The cluster is at capacity, so preemption is the only way to place anything new.
• A PriorityClass assigned more widely than intended, for example as a namespace default.
• System-critical pods preempting application workloads, which is by design.
• A workload with no priority class competing against one that has a high one.

How to diagnose it

1. Read the preempted pod's events: kubectl describe pod POD names the preemptor.
2. Check both pods' priorities: kubectl get pod POD -o jsonpath='{.spec.priority} {.spec.priorityClassName}'.
3. List the priority classes defined in the cluster: kubectl get priorityclasses.
4. Check cluster capacity — frequent preemption means the cluster is genuinely short of resources.
5. Check whether a namespace or an admission controller is assigning a default priority class.

How to fix it

1. Add capacity if preemption is happening routinely. It is a triage mechanism, not a capacity plan.
2. Assign priority classes deliberately across workloads, so the ordering reflects actual importance.
3. Use preemptionPolicy: Never on high-priority pods that should wait rather than displace others.
4. Protect critical workloads with an appropriate priority class rather than assuming the default is safe.
5. Review any default priority class applied at the namespace level.

Notes

Preemption respects PodDisruptionBudgets on a best-effort basis only — the scheduler prefers not to violate them, but will if that is the only way to place a higher-priority pod. A PDB is therefore not a defence against preemption.

Related

• Evicted — Pod removed because the node ran short of resources
• FailedScheduling — The scheduler could not find a suitable node

Sources

• Kubernetes documentation — Pod Priority and Preemption
• Kubernetes documentation — Disruptions
• Kubernetes documentation — Kubernetes Scheduler