How QoS is Assigned
Kubernetes examines the resources section of every container in your Pod to determine its QoS class. The rules are precise.
1. Guaranteed
Every container in the Pod must have both CPU and Memory requests and limits set, and for each resource, request must exactly equal limit. Guaranteed Pods get their CPU and memory reserved exclusively. The kernel assigns them the lowest OOM score (-998), making them nearly immune to OOM killing. The trade-off: they cannot burst beyond their declared resources, so you must size them accurately.
2. BestEffort
No container in the Pod has any requests or limits set for either CPU or memory — no resources section at all. BestEffort Pods use whatever CPU and memory happens to be available. They get the highest OOM score (1000), making them the first target for the kernel's OOM killer. Use these only for truly disposable workloads — batch jobs, development experiments — where losing the Pod is acceptable.
3. Burstable
Any Pod that doesn't qualify as Guaranteed or BestEffort. The most common pattern: requests are set lower than limits, allowing the container to burst when resources are available. Burstable Pods get an OOM score between 2 and 999, calculated proportionally based on how much memory they are using relative to their request. A Burstable Pod using 3× its memory request is more likely to be killed than one using 1.1× its request.
A common interview question: "If I want my production database to never be OOM-killed, what QoS class should I use and how do I achieve it?" The answer is Guaranteed — set requests equal to limits for both CPU and memory on every container in the Pod, including init containers. A follow-up trap: "What about sidecar containers?" Yes, every container counts. If your logging sidecar has no resource limits, the entire Pod drops to Burstable.