Understanding Kubernetes Resources

Workload Type & Quality of Service Class

Kubernetes categorizes Pods into specific Quality of Service (QoS) classes based on the resource requests and limits defined for their Containers. This classification influences how Pods are managed and determines their priority during resource contention.

Best-Effort QoS
(disposable apps)

Best-Effort QoS is suited for non-critical, disposable application workloads, such as background tasks, batch jobs, and development/testing environments, where reliability and guaranteed performance are not essential. These workloads have no resource guarantees, as Best-Effort Pods do not specify CPU or memory requests or limits. This allows them to utilize leftover resources on the Node, leading to high resource utilization efficiency when the Node is underutilized. However, when nodes experience resource constraints, Best-Effort Pods are the first to be throttled, terminated and evicted, as they have the lowest priority in the Kubernetes resource allocation hierarchy.

Best-Effort Pods (no resource requests) are the first to be evicted.

( REQUESTS=<blank> LIMITS=<blank> )

Guaranteed QoS
(critical apps)

Best for critical applications requiring consistent performance. Pods are guaranteed their requested resources and are throttled (CPU) or killed (OOM) if they exceed their set limits, regardless of the Node’s overall resource availability. To mitigate potential resource underutilization, careful scheduling and resource allocation planning are essential to ensure that resources are fully utilized without compromising the guarantees provided to critical workloads.

OOM (Out of Memory) in Kubernetes occur when a container exceeds its memory limits, not the requests.

( REQUESTS == LIMITS )

Burstable QoS
(Batch, non-critical/spiky apps)
[Overcommit]

Suitable for non-critical, spiky or batch processing applications that can tolerate variability. Burstable QoS pods always get at least their requests allocation, as it’s reserved for them. If spare capacity exists on the node, these workloads can make use of it however, when resources are scarce, Burstable pods can be throttled (CPU) or even OOM killed (memory) when exceeding their requests limits. This is not usually a problem for non-interactive workloads such as batch processing tasks that can be re-run.

Burstable QoS strikes a balance between efficiency and flexibility.

( REQUESTS=XX LIMITS= greaterThan REQUESTS )

OR

( REQUESTS=XX LIMITS= <blank> )

If requests are set, but limits are not specified (blank). In this case, Kubernetes treats the limits as equal to the Node’s capacity, effectively allowing the container to use as much resource as is available, but the Pod will still be classified as Burstable.

This Burstable classification gives the container more priority than Best-Effort Pods, but less than Guaranteed Pods under resource contention.