When the Node Runs Out of Room
Even with Requests and Limits set, a Node can become memory-pressured — for example, if many containers are bursting toward their Limits simultaneously. When this happens, Kubernetes must evict some Pods to protect the Node. Which Pods get evicted first?
Kubernetes assigns every Pod a Quality of Service (QoS) class based on how its Requests and Limits are configured. This class determines eviction priority.
Guaranteed (Evicted Last)
Both CPU and memory have Requests equal to Limits (for example, both set to 512Mi memory and 500m CPU). The container gets exactly what it asked for, no more, no less.
Use for: critical system components, databases, anything that must not be interrupted.
Burstable (Evicted Second)
Requests are set but Limits are higher than Requests (or Limits are omitted) — for example, requesting 256Mi/250m with limits of 512Mi/500m. The container is guaranteed its Request but can burst higher.
Use for: most application workloads. This is the most common and practical class.
BestEffort (Evicted First)
No Requests or Limits are set at all. Kubernetes gives these Pods whatever is left over and evicts them immediately under any memory pressure.
Avoid BestEffort for anything important. It is appropriate only for truly disposable batch jobs where losing the Pod mid-execution is acceptable.
Why This Matters
When you see a Pod evicted unexpectedly, check its QoS class in the Pod's status. If it's BestEffort or Burstable and the Node was under memory pressure, the eviction was intentional — Kubernetes was protecting higher-priority workloads.