Pod Eviction and QoS: Why Kubernetes Picks Which Workloads Die First

A Kubernetes node does not gracefully degrade when it runs out of memory. The kernel's OOM killer is sudden and indiscriminate, so the kubelet tries to get ahead of it. When memory, disk, or PID pressure crosses a threshold, the kubelet starts evicting pods on its own terms. Which pods go first is not random. It is a ranked decision based on QoS class and how far each pod has exceeded its requests.

Three QoS classes exist, and you do not pick them directly. The scheduler infers them from your pod spec.

1. Guaranteed. Every container has memory and CPU requests equal to its limits. These pods get the strongest protection.
2. Burstable. At least one container has a request set, but request and limit do not match across the board. Most real workloads land here.
3. BestEffort. No requests or limits anywhere in the pod spec. Cheapest to schedule, first to die.

Under memory pressure, the kubelet evicts in this order: BestEffort pods first, then Burstable pods that are using more memory than they requested (ranked by how much they exceeded the request), then Guaranteed pods only as a last resort. The logic is straightforward. Pods that promised nothing get nothing. Pods that asked for X but are now sitting at 4X are the next obvious target. Pods that asked for X and stayed at X are doing what they said they would do.

This is why requests and limits are not just scheduler hints. They are your eviction insurance. A request says "reserve this much for me." A limit says "kill me if I exceed this." Together they decide your QoS, and your QoS decides whether you survive a noisy neighbor.

The production failure I keep seeing: a team ships a critical service to a new cluster and the manifest has no resource requests. Maybe it was a Helm chart with empty defaults. Maybe someone copied a tutorial. The pod is now BestEffort. It runs fine for weeks. Then a sister workload on the same node has a traffic spike, memory pressure rises, and the kubelet starts evicting the BestEffort pods first. The "critical" service goes down while a background batch job sits there untouched because at least that one had requests set.

The fix is one line in the pod spec, but the lesson is bigger. In Kubernetes, importance is not declared by intent. It is declared by resource requests. If you did not set them, the cluster assumes you do not care.