Kubernetes QoS Calculator
Enter the requests and limits of each container in a pod. See which QoS class Kubernetes assigns, how early the pod is evicted under pressure, and where it risks an OOM kill or CPU throttling.
Runs entirely in your browser — nothing you enter here is sent to a server.
How Kubernetes assigns a QoS class
You never set a pod's Quality of Service class directly. Kubernetes derives it from the resource requests and limits of the pod's containers, and uses it for one purpose: deciding which pods to kill first when a node runs out of memory. There are three classes, and the rules are stricter than most people expect — a single container without a limit is enough to change the class of the whole pod.
Guaranteed
Every container sets CPU and memory limits, and requests equal to them. Evicted last. Needed for exclusive CPU pinning with the static CPU manager.
Burstable
At least one request or limit is set, but the Guaranteed rule is not met. May use spare capacity; evicted in order of how far memory use exceeds the request.
BestEffort
No requests or limits on any container. Uses whatever is free and is the first to go under pressure. Acceptable only for work you can afford to lose.
Requests and limits
The request is what the scheduler reserves on a node. The limit is the hard ceiling enforced at runtime. Setting only a limit makes the request equal to it.
Memory kills, CPU throttles
The two resources fail differently. Memory cannot be taken back, so a container that goes over its memory limit is killed at once — status OOMKilled, exit code 137 — and restarted. CPU can be withheld, so a container at its CPU limit is merely paused until the next scheduling period. Nothing crashes; requests simply take longer, which makes throttling hard to spot unless you watch container_cpu_cfs_throttled_periods_total.
Practical defaults: set the memory request equal to the memory limit, at about 25% above the observed peak, so the pod can never be evicted for using memory it was promised. Set the CPU request to typical usage. Whether to set a CPU limit at all is debated — many teams leave it off for latency-sensitive services to avoid throttling, and rely on requests for fair sharing.
Frequently asked questions
What are the Kubernetes QoS classes?
Guaranteed, Burstable and BestEffort. They are assigned automatically from the pod's resource requests and limits and determine the order in which pods are evicted when a node is short of resources.
How do I make a pod Guaranteed?
Give every container in the pod — including init and sidecar containers — both a CPU and a memory limit, with requests equal to those limits. Setting only limits works too, since requests then default to the limits.
What does OOMKilled mean?
The container exceeded its memory limit and the kernel killed it; the exit code is 137. Raise the limit, or find out why memory grows — a leak, a cache without a bound, or a JVM heap sized larger than the container.
Should I set CPU limits?
It depends. Limits make behaviour predictable and are required for the Guaranteed class, but they cause throttling and latency spikes. For latency-sensitive services, many teams set CPU requests only and always set memory limits.