Pod QoS Classes: Guaranteed, Burstable, BestEffort

WHY IT EXISTS: Kubernetes runs many workloads on shared nodes. When a node exhausts memory or CPU, something must be killed or throttled. Without a classification system, the kubelet would have no principled way to decide which pods to sacrifice first. QoS classes exist to answer one question: if the node is under pressure, whose pods die first?

THE MENTAL MODEL: Think of QoS classes as boarding groups for a lifeboat, not seat upgrades. They do not guarantee speed, isolation, or SLA. They only determine eviction order. A Guaranteed pod is not faster than a BestEffort pod; it is simply the last one the kubelet will throw overboard when the node is sinking.

HOW IT WORKS: The kubelet looks at CPU and memory requests and limits for every container in a pod. Guaranteed means every container has requests equal to limits, and limits are set only for CPU and memory, with no extra resources requested. Burstable means at least one container has a request lower than its limit, or a limit is missing. BestEffort means no container has any CPU or memory requests or limits set. Under node pressure, the eviction manager targets BestEffort first, then Burstable, then Guaranteed last. Within Burstable, the kubelet sorts by usage relative to request, killing the biggest overages first.

WHEN TO USE IT: Use Guaranteed for critical system components or stateful workloads where unexpected termination is unacceptable, such as databases or payment processors. Use Burstable for typical applications that have baseline needs but can handle occasional spikes, like web servers. Use BestEffort only for truly optional batch jobs or debug sidecars where failure is harmless.

WHEN NOT TO USE IT: Do not use QoS classes as a performance tuning tool. Setting limits equal to requests to chase a Guaranteed badge will throttle your workload during traffic spikes and can cause unnecessary OOM kills if the limit is too low. Do not assume BestEffort pods are free; they still consume node resources and are the first to be evicted, which can cascade into retry storms if a controller immediately recreates them.

ONE CANONICAL EXAMPLE: A node has 8 GiB of memory. Pod A is a Redis cache with a 2 GiB request and 2 GiB limit, Guaranteed. Pod B is an API server with a 1 GiB request and 4 GiB limit, Burstable. Pod C is a log scrapper with no requests or limits, BestEffort. If a memory leak in Pod B pushes node memory to the eviction threshold, the kubelet kills Pod C first. If pressure continues, it evicts Pod B. Pod A survives until the node is truly out of memory, giving operators time to drain or scale before data loss.