Kubernetes Quality of Service Classes

Quality of Service (QoS) classes determine how Kubernetes treats Pods under resource pressure. The QoS class is automatically assigned based on a Pod’s resource profile - specifically, the relationship between requests and limits.

The Three QoS Classes

Guaranteed

Criteria:

• Every container has CPU and memory requests and limits
• Requests equal limits for both CPU and memory

Behavior:

• Highest priority during eviction (last to be killed)
• Gets exactly what it requested, no more, no less
• Most predictable performance

Use case: Production workloads requiring stable, predictable performance.

resources:
  requests:
    memory: "256Mi"
    cpu: "500m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Burstable

Criteria:

• At least one container has a request or limit for CPU or memory
• Requests and limits don’t match (or only one is specified)

Behavior:

• Medium priority during eviction
• Can use more than requested if available (up to limit)
• May be throttled or evicted under pressure

Use case: Applications that benefit from burst capacity but can tolerate some resource variability.

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"
    cpu: "1000m"

BestEffort

Criteria:

• No container in the Pod has requests or limits

Behavior:

• Lowest priority during eviction (first to be killed)
• Can use any available resources
• No guarantees of getting any resources

Use case: Low-priority batch jobs, development workloads, or processes that gracefully handle interruption.

# No resources block at all
containers:
- name: app
  image: myapp:latest

Eviction Order

When a node runs out of incompressible resources (memory, disk), Kubernetes evicts Pods in this order:

1. BestEffort Pods (highest usage first)
2. Burstable Pods exceeding their requests (by percentage over request)
3. Burstable Pods within their requests
4. Guaranteed Pods (only if system processes need resources)

Within each class, actual usage relative to requests determines eviction order.

QoS vs Priority

QoS classes are orthogonal to Pod Priority:

• QoS is automatic, based on resource profiles
• Priority is explicit, using PriorityClass
• Both influence scheduling and eviction but through different mechanisms

A low-priority Guaranteed Pod gets evicted before a high-priority BestEffort Pod, but among Pods of equal priority, QoS class matters.

Resource Type Implications

QoS behavior differs by resource type:

Compressible (CPU): Pods are throttled, not killed. Even BestEffort Pods can run slowly rather than being evicted.

Incompressible (memory): Pods are killed (OOMKilled) when limits are exceeded. QoS class determines which Pods are selected for killing when node memory is exhausted.

This connects to the fundamental distinction in resource profiles between compressible and incompressible resources.

Setting QoS Implicitly

You never explicitly set QoS class - Kubernetes assigns it based on your resource specification:

Resource Spec	QoS Class
No requests/limits	BestEffort
requests < limits	Burstable
requests = limits (all resources)	Guaranteed
Only requests (no limits)	Burstable