Pod Eviction Calculator
Determine the order pods would be evicted under node pressure, ranked by priority class and Quality of Service (QoS) class.
Inputs
Pods with no CPU/memory requests or limits set.
Pods with requests set below their limits (or only some resources set).
Pods where requests equal limits for every resource.
Of the burstable pods, percent also assigned a low PriorityClass, evicted before other burstable pods.
Pods at Elevated Eviction Risk
44.8%
BestEffort Pods (Evicted First)
8pods
Guaranteed Pods (Evicted Last)
6pods
Eviction Order Detail
0
Step by step
Low-priority Burstable pods
15 × 30%
= 5
Pods at elevated eviction risk
(8 + 5) ÷ 29
= 44.8%
How it works
When a node comes under CPU, memory, or disk pressure, the kubelet evicts pods in a defined order: BestEffort pods (no requests/limits) go first since they have no reserved resources to protect them, then Burstable pods ranked partly by PriorityClass and by how far their usage exceeds their requests, and Guaranteed pods (requests equal limits) go last, evicted only under the most extreme pressure. PriorityClass acts as a tiebreaker within and across these QoS bands, letting critical low-QoS pods still be protected relative to non-critical pods of the same class.
Formula
elevatedRisk% = ((bestEffortPods + lowPriorityBurstable) / totalPods) × 100
- B_e
- BestEffort pods (evicted first)
- B_l
- Low-priority Burstable pods
- N
- Total pods on the node
- E
- Percentage of pods at elevated eviction risk
Frequently Asked Questions
What determines a pod's QoS class?
It's derived automatically from its resource spec: Guaranteed requires CPU and memory requests to equal limits for every container; BestEffort has no requests or limits set at all; Burstable is everything in between — you cannot set QoS class directly.
Can a high-priority BestEffort pod avoid eviction before a low-priority Guaranteed pod?
Under standard node-pressure eviction, QoS class is the primary sort key — BestEffort pods are generally evicted before Burstable and Guaranteed pods regardless of PriorityClass, though PriorityClass does influence scheduling preemption separately from kubelet eviction.
How can I protect a critical Burstable pod from early eviction?
Set requests closer to (or equal to) actual usage/limits to shift it toward Guaranteed QoS, and assign it a higher PriorityClass — both reduce its relative eviction risk compared to lower-priority or under-provisioned pods on the same node.