Pod QoS Class Checker
Deduce Kubernetes QoS classes (Guaranteed, Burstable, BestEffort) and node eviction priorities from container resource specs — entirely on this device.
Every container in the Pod has matching CPU and Memory requests and limits.
Do it offline:$
How to use it
- Enter the container specifications for your Kubernetes Pod including name, CPU request/limit, and Memory request/limit.
- Add multiple containers if testing multi-container Pods or sidecar patterns.
- Inspect the calculated QoS class: Guaranteed, Burstable, or BestEffort.
- Review Kubelet eviction risk and OOM kill score adjustments to safeguard critical microservices.
Evaluate Kubernetes Pod Quality of Service (QoS) classes and out-of-memory eviction priorities based on container CPU and memory requests and limits specifications.
How it works
Kubernetes assigns a Quality of Service (QoS) class to pods to make scheduling and eviction decisions when nodes experience memory or CPU starvation.
Guaranteed requires every container in the Pod to specify both CPU and Memory requests and limits, with request values exactly matching limit values.
Burstable applies when at least one container specifies requests or limits, but the Pod does not satisfy the strict requirements of Guaranteed.
BestEffort pods have neither CPU nor Memory limits or requests set for any container. These pods receive an OOM score adjustment of 1000 and are the very first to be killed under node memory pressure.
Examples
Every example on this page is executed against the same engine that powers the tool, on every build.
Gotchas worth knowing
Common errors
FAQ
What is the OOM score adjustment difference between Guaranteed and BestEffort?
Guaranteed pods receive an oom_score_adj of -997 (nearly immune to eviction unless system processes run out of memory). In contrast, BestEffort pods receive an oom_score_adj of 1000, making them the first target for termination by the Linux OOM killer.
Does an InitContainer impact the Pod QoS class?
Yes, in Kubernetes, init containers are evaluated alongside regular containers. If an init container lacks resource requests or limits matching the regular containers, the Pod can downgrade from Guaranteed to Burstable.
Why should production workloads aim for Guaranteed or well-calibrated Burstable?
Predictable performance and stability! Guaranteed prevents unpredictable throttling and eviction. For variable workloads, well-calibrated Burstable prevents over-allocation while ensuring the node scheduler reserves sufficient capacity.