Understanding QoS Classes: Guaranteed vs Burstable vs BestEffort

Intermediate · 3 min read

The Hidden Cost of Resource Ambiguity

When you deploy a workload to Kubernetes, the scheduler does not just look at CPU and memory requests; it evaluates Quality of Service (QoS) classes. This classification is not merely metadata—it dictates the priority of eviction during node pressure, the order of resource allocation, and the behavior of the OOM killer. Understanding these three tiers—Guaranteed, Burstable, and BestEffort—is critical for building resilient systems that survive cluster stress.

Prerequisites and Version Context

This guide assumes a working knowledge of Pod specifications, resource requests, and limits. We assume a standard Kubernetes cluster running version 1.20 or later, where QoS classification logic remains consistent. No external tools are required beyond `kubectl`.

How QoS Classification Works Under the Hood

Kubernetes determines a Pod’s QoS class by comparing its resources.requests against its resources.limits for all containers within that Pod. The logic is strict:

1. Guaranteed: Every container in the Pod must have equal requests and limits. If one container has them set and another does not, the entire Pod fails this class. This class provides the strongest guarantee that resources will be available when needed.
2. Burstable: At least one container in the Pod must have a request set. If requests and limits are not identical across all containers, the Pod falls into this category. It allows for “bursting” above the request up to the limit, but offers no guarantees against eviction.
3. BestEffort: Neither requests nor limits are specified for any container. These Pods consume whatever resources are available after Guaranteed and Burstable Pods are satisfied. They are the first candidates for eviction.

Deep Dive: The Eviction Priority

The kubelet uses QoS classes to determine eviction order when a node runs out of memory or disk. The hierarchy is clear:

• Lowest Priority: BestEffort Pods are evicted first.
• Medium Priority: Burstable Pods are evicted next if pressure persists.
• Highest Priority: Guaranteed Pods are evicted last. Within this class, pods with higher total resource allocations are evicted before those with lower allocations.

Verification Example

You can verify your Pod’s QoS class by inspecting the status field. Run the following command:

kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'

A correctly configured Guaranteed pod will return Guaranteed. A common mistake is setting limits without requests, which inadvertently downgrades a Pod from Guaranteed to Burstable, exposing it to premature eviction.

Common Mistakes and Cleanup

A frequent error is assuming that setting a high limit automatically guarantees stability. Without a matching request, the scheduler may place the Pod on a node that cannot strictly satisfy that request, leading to throttling or eviction. To clean up test environments, always delete the namespace containing your experiments:

kubectl delete namespace qos-demo

Conclusion

Designing for QoS is about aligning application reliability with infrastructure constraints. Use Guaranteed for stateful services like databases, Burstable for web frontends, and BestEffort only for non-critical batch jobs.

Architecture

References

• Pod Quality of Service Classes
• Configure Quality of Service for Pods

---

This article was drafted with AI assistance and reviewed by the DevOpsEngine editors before publication.