Kubernetes Quality of Service (QoS) classes with examples and YAML snippets

QoS classes determine the priority of pods when it comes to resource allocation and eviction. There are three classes: Guaranteed, Burstable, and BestEffort. Each has different resource request and limit configurations.

For Guaranteed, the pod must have equal requests and limits for all containers in all resources (CPU and memory). If a container specifies a limit for a resource but doesn't specify a request, the request is automatically set to the limit. So both CPU and memory need to have requests equal to limits.

Burstable pods have at least one container with a request or limit set, but they don't meet the Guaranteed criteria. For example, if a container has a memory request but no limit, or different requests and limits.

BestEffort pods have no requests or limits set for any resources. These are the lowest priority and can be evicted first under resource pressure.

Now, I need to create YAML examples for each class. Let me draft them.

Guaranteed example: The pod has both resources with requests equal to limits. So in the container spec, both CPU and memory have requests and limits set, and they're the same.

Burstable example: Maybe set a request but not a limit, or different values. For instance, a container with a memory request of 128Mi and a limit of 256Mi, and CPU request of 250m without a limit. That would make it Burstable.

BestEffort is straightforward: no resources section at all in the container.

Wait, but in Kubernetes, if you don't specify resources, it's BestEffort. If you specify requests without limits, limits default to the node's capacity, but the QoS class would still be Burstable if any container has requests. So BestEffort is only when no requests or limits are set for any container in the pod.

Kubernetes uses Quality of Service (QoS) classes to prioritize Pod scheduling and eviction when resources (CPU/memory) are scarce. The three QoS classes are Guaranteed, Burstable, and BestEffort, determined by resource requests and limits in the Pod configuration. Below are examples and explanation

. Guaranteed QoS
Criteria:

All containers in the Pod must have equal requests and limits for both CPU and memory.

If only limits are defined (without explicit requests), Kubernetes sets requests = limits.

Use Case: Mission-critical workloads (e.g., databases) needing strict resource guarantees. ,

`apiVersion: v1
kind: Pod
metadata:
name: guaranteed-pod
spec:
containers:

• name: nginx image: nginx resources: requests: cpu: "500m" # 0.5 CPU core memory: "512Mi" limits: cpu: "500m" # Must match requests memory: "512Mi"`

Equivalent Shortcut (implicit requests = limits):

resources:
limits:
cpu: "500m"
memory: "512Mi"

1. Burstable QoS Criteria:

At least one container has a request or limit set, but not all resources meet the requests = limits rule.

Common when containers define requests without limits or use different values.

Use Case: Applications needing baseline resources but allowed to burst (e.g., web servers).

Example YAML:

`apiVersion: v1
kind: Pod
metadata:
name: burstable-pod
spec:
containers:

• name: nginx image: nginx resources: requests: cpu: "250m" # Requested CPU memory: "128Mi" limits: cpu: "500m" # Higher limit than request memory: "256Mi"
• name: sidecar image: busybox resources: requests: memory: "64Mi" # No CPU request/limit`

Key Behavior:

The Pod is prioritized over BestEffort but can be evicted under pressure if Guaranteed Pods need resources

1. BestEffort QoS Criteria:

No container in the Pod has requests or limits defined for any resource.

Use Case: Non-critical, best-effort workloads (e.g., batch jobs, test environments).

Example YAML:

apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: nginx
    image: nginx
    # No resources section

Key Behavior:

First to be evicted under resource pressure.

Suitable for workloads that can tolerate interruptions.

QoS Class Determination Flowchart

If all containers have requests == limits for all resources → Guaranteed.
If any container has requests or limits defined, but not meeting Guaranteed criteria → Burstable.
If no containers have requests or limits → BestEffort.

How to Check QoS Class
Run:

kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'

Eviction Priority Order

BestEffort → Lowest priority.
Burstable → Medium priority (lower if it exceeds requests).
Guaranteed → Highest priority (evicted only if absolutely necessary).

By configuring requests and limits appropriately, you ensure critical workloads stay online during resource contention.