Kubernetes assigns every Pod a QoS class based on its resource configuration. This class determines the order in which Pods are killed when a node runs out of memory. Understanding QoS is essential for protecting critical workloads from eviction.

1. The Three QoS Classes

QoS is automatically assigned — you don't set it directly. It's derived from how you configure requests and limits:

Guaranteed

# Every container must have requests = limits for BOTH CPU and memory:
spec:
  containers:
    - name: db
      resources:
        requests:
          cpu: 1000m
          memory: 2Gi
        limits:
          cpu: 1000m         # ← must equal request
          memory: 2Gi        # ← must equal request
    - name: sidecar
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 100m          # ← every container must match
          memory: 128Mi

# Check QoS:
kubectl get pod db-0 -o jsonpath='{.status.qosClass}'
# Guaranteed

Burstable

# At least one container has a request OR limit, but not all requests = limits:
spec:
  containers:
    - name: app
      resources:
        requests:
          cpu: 100m
          memory: 256Mi
        limits:
          cpu: 500m          # ← limit ≠ request → Burstable
          memory: 512Mi      # ← limit ≠ request

BestEffort

# No resources specified on ANY container:
spec:
  containers:
    - name: batch
      image: busybox
      # No resources block at all → BestEffort

2. Eviction Order Under Memory Pressure

When a node's available memory drops below the eviction threshold, the kubelet must choose which Pods to kill. QoS class determines the order:

Detailed Eviction Logic

1. BestEffort Pods — evicted first (sorted by memory usage, highest first)
2. Burstable Pods exceeding their memory request — evicted next (sorted by how much they exceed their request, as a percentage)
3. Burstable Pods within their memory request — evicted only if pressure continues
4. Guaranteed Pods — evicted only as a last resort (only if system processes need memory)

OOM Score Adjustment

Kubernetes sets the Linux oom_score_adj based on QoS class:

# The formula for Burstable:
# oom_score_adj = 1000 - 10 * (memory_request / memory_limit * 100)
# Example: request=256Mi, limit=512Mi → 1000 - 10*(50) = 500

3. Choosing the Right QoS for Your Workloads

The Trade-Off

# Guaranteed:
# ✅ Maximum protection from eviction
# ✅ Predictable performance (no burst, no throttling if request=limit at right level)
# ❌ Cannot burst above request — wastes unused capacity
# ❌ Must know exact resource needs upfront

# Burstable:
# ✅ Can burst when spare capacity exists
# ✅ Flexible — only needs approximate sizing
# ❌ Can be evicted under pressure
# ❌ Performance varies based on node load

# BestEffort:
# ✅ Uses free resources without any reservation
# ❌ First to be killed — no guarantees whatsoever
# ❌ Can starve when node is busy

Checking QoS Class

# Check all Pods' QoS:
kubectl get pods -o custom-columns=\
NAME:.metadata.name,\
QOS:.status.qosClass,\
CPU_REQ:.spec.containers[0].resources.requests.cpu,\
MEM_REQ:.spec.containers[0].resources.requests.memory,\
CPU_LIM:.spec.containers[0].resources.limits.cpu,\
MEM_LIM:.spec.containers[0].resources.limits.memory

4. QoS and Node Allocatable

Understanding how QoS interacts with the node's resource accounting:

# Node capacity:         16Gi memory
# kube-reserved:         1Gi
# system-reserved:       1Gi
# eviction-threshold:    100Mi
# ─────────────────────────────
# Allocatable:           13.9Gi  ← what scheduler sees

# Sum of all Pod requests must fit within Allocatable
# A Guaranteed Pod with 4Gi request takes exactly 4Gi from Allocatable
# A BestEffort Pod takes 0 from Allocatable (scheduler thinks node has more room)

# This is why BestEffort can cause overcommit:
# Node may have 13.9Gi Allocatable but 16Gi of actual usage if BestEffort Pods burst

Summary