Kubernetes QoS Calculator
Container resources
CPU in millicores (500m is half a core), memory in MiB. Leave a field empty for unset, which is exactly how the kubelet sees it.
Middle of the eviction order. Can use spare capacity, and can lose it under pressure.
- notememory limit above request overcommits the node. Under pressure this pod is evicted before Guaranteed pods.
Requests and limits in, QoS class and eviction consequences out.
What a Kubernetes QoS class is
A label the kubelet attaches to every pod when it is admitted, derived entirely from the requests and limits its containers declare. There is no field to set it in: you get the class your resource spec earns. Its purpose is to rank pods against each other for eviction, so when a node runs out of memory the class decides who is killed first.
Guaranteed, Burstable and BestEffort
Three rules, checked in order:
- Guaranteed: every container sets CPU and memory requests and limits, and each request equals its limit.
- BestEffort: no container sets any request or limit at all.
- Burstable: anything else.
The rule that catches people is how unforgiving Guaranteed is. One container in a pod missing one value, or a request set a little below its limit, drops the entire pod to Burstable. Sidecars are the usual culprit: the application container is specified carefully and the log shipper beside it is not.
What the class actually changes
Eviction order under memory pressure. BestEffort pods are removed first, then Burstable pods that have grown past their requests, and Guaranteed pods last. For a stateful or latency-critical service, the class is effectively its seat on the lifeboat.
Worth separating from a different mechanism people conflate with it: exceeding a memory limit gets a container OOM-killed by the kernel immediately, whatever its class. Exceeding a CPU limit only throttles it. That asymmetry is why a missing memory limit is worth flagging, since without one a leak grows until the node itself is in trouble and the eviction order decides who pays for it.
Should everything be Guaranteed?
No. Guaranteed reserves the full limit for every pod, which gives up the overcommit that makes a cluster affordable. The usual shape is Guaranteed for critical stateful services, Burstable with honest requests for the bulk of workloads, and BestEffort only for jobs you would not mind losing. Setting requests you know to be inflated in order to reach Guaranteed just moves the waste somewhere harder to see.
Kubernetes QoS FAQs
What are the three QoS classes?
Guaranteed: every container sets requests and limits for both CPU and memory, with request equal to limit. BestEffort: nothing is set at all. Burstable: everything in between. One container falling short of the Guaranteed rules makes the whole pod Burstable.
What is a QoS class in Kubernetes?
A label the kubelet assigns to every pod at admission time, based purely on the requests and limits its containers declare. You never set it directly; it is derived. Its job is to rank pods for eviction when a node runs short of resources, so it decides which workloads are sacrificed first when the node is under pressure.
How does Kubernetes decide the QoS class?
Three rules, checked in order. If every container in the pod sets both CPU and memory requests and limits, and each request equals its limit, the pod is Guaranteed. If no container sets any request or limit at all, it is BestEffort. Everything else is Burstable. A single container missing a single value is enough to drop the whole pod from Guaranteed to Burstable, which is the rule that surprises people most.
Why does the QoS class matter?
It sets the eviction order when a node runs short of memory: BestEffort pods go first, then Burstable pods exceeding their requests, and Guaranteed pods last. For anything stateful or latency-critical, the class is effectively your seat on the lifeboat.
Should everything be Guaranteed then?
No. Guaranteed reserves the full limit for every pod, which forfeits the overcommit that makes clusters efficient. A common pattern is Guaranteed for critical stateful services, Burstable with honest requests for most workloads, and BestEffort only for genuinely disposable jobs.
What happens when a container exceeds its memory limit?
It is OOM-killed by the kernel, regardless of QoS class. Exceeding the CPU limit merely throttles. That asymmetry is why the calculator flags missing memory limits: without one, a leak grows until the node itself comes under pressure and the eviction order decides who pays.
Is my configuration sent anywhere?
No. Classification happens in your browser and the page works offline.