Quality of Service classes (Guaranteed, Burstable, BestEffort) in Kubernetes - Deep Dive

Overview - Quality of Service classes (Guaranteed, Burstable, BestEffort)

What is it?

Quality of Service (QoS) classes in Kubernetes define how the system treats pods when resources are limited. There are three classes: Guaranteed, Burstable, and BestEffort. These classes help Kubernetes decide which pods get priority for CPU and memory during high demand. They are based on how resource requests and limits are set for each pod.

Why it matters

Without QoS classes, Kubernetes would not know which pods are more important or how to fairly share limited resources. This could cause critical applications to slow down or crash when the cluster is busy. QoS classes ensure that important workloads get the resources they need, improving stability and performance for users.

Where it fits

Learners should first understand basic Kubernetes concepts like pods, containers, and resource requests/limits. After QoS classes, they can explore advanced scheduling, resource quotas, and cluster autoscaling to manage resources efficiently.

Mental Model

Core Idea

Kubernetes uses QoS classes to prioritize pods based on their resource guarantees, ensuring fair and stable resource sharing under pressure.

Think of it like...

Imagine a busy restaurant kitchen where orders are prioritized: VIP guests get their meals cooked first (Guaranteed), regular customers get served as soon as possible (Burstable), and walk-ins wait until there's free time (BestEffort).

┌───────────────┐
│   Pod QoS     │
├───────────────┤
│ Guaranteed    │  ← Pods with equal requests and limits
│ Burstable     │  ← Pods with requests less than limits
│ BestEffort    │  ← Pods with no requests or limits
└───────────────┘

Resource Pressure → Kubernetes evicts pods starting from BestEffort, then Burstable, keeping Guaranteed last.

Build-Up - 7 Steps

1

Foundation

Understanding Kubernetes Pods and Resources

Concept: Pods run containers and can request CPU and memory resources.

In Kubernetes, a pod is the smallest unit that runs one or more containers. Each container can ask for a certain amount of CPU and memory (called requests) and can set a maximum limit for these resources (called limits). Requests tell Kubernetes how much resource the pod needs to run well, while limits cap the maximum it can use.

Result

Pods have defined resource needs that Kubernetes can use to schedule them on nodes.

Knowing how pods request and limit resources is essential to understanding how Kubernetes manages workload priorities.

2

Foundation

Resource Requests vs Limits Explained

Concept: Requests guarantee resources; limits cap usage to prevent overuse.

A resource request is like reserving a seat at a concert — the pod expects to get at least this much CPU or memory. A limit is like a maximum ticket price — the pod cannot use more than this. If a pod tries to use more than its limit, Kubernetes may throttle or kill it.

Result

Pods have a guaranteed minimum and a maximum resource usage boundary.

Understanding requests and limits clarifies how Kubernetes decides pod priority and resource allocation.

3

Intermediate

Defining Guaranteed QoS Class

🤔Before reading on: do you think a pod with equal requests and limits for all containers is Guaranteed or Burstable? Commit to your answer.

Concept: Guaranteed class requires all containers in a pod to have equal CPU and memory requests and limits.

If every container in a pod sets the same value for CPU and memory requests and limits, Kubernetes marks the pod as Guaranteed. This means the pod has a strict resource reservation and will be the last to be evicted under resource pressure.

Result

Pod is classified as Guaranteed and gets highest priority for resources.

Knowing the strict equality rule helps you design pods that get the strongest resource guarantees.

4

Intermediate

Understanding Burstable QoS Class

🤔Before reading on: if a pod has requests less than limits, is it Burstable or BestEffort? Commit to your answer.

Concept: Burstable class applies when pods have requests set but limits are higher than requests.

When a pod sets resource requests but allows higher limits, Kubernetes classifies it as Burstable. This means the pod is guaranteed the requested resources but can use more if available. Under pressure, Burstable pods are evicted after BestEffort pods but before Guaranteed ones.

Result

Pod is classified as Burstable and can use extra resources when free.

Understanding Burstable helps balance guaranteed resources with flexibility for bursts.

5

Intermediate

Exploring BestEffort QoS Class

Concept: BestEffort class is for pods without any resource requests or limits.

If a pod does not specify any CPU or memory requests or limits, Kubernetes marks it as BestEffort. These pods get the lowest priority and are the first to be evicted when the node runs out of resources.

Result

Pod is classified as BestEffort and has no guaranteed resources.

Knowing BestEffort helps avoid surprises when pods get evicted quickly under load.

6

Advanced

How Kubernetes Uses QoS for Eviction

🤔Before reading on: do you think Kubernetes evicts Guaranteed pods before or after BestEffort pods under pressure? Commit to your answer.

Concept: Kubernetes evicts pods based on QoS class priority during resource shortages.

When a node runs low on memory or CPU, Kubernetes evicts pods to free resources. It starts with BestEffort pods, then Burstable, and finally Guaranteed pods last. This eviction order protects critical workloads and maintains cluster stability.

Result

Pods with lower QoS classes are removed first to protect higher priority pods.

Understanding eviction order helps design pods that survive resource pressure.

7

Expert

Subtle Effects of Mixed Container QoS in Pods

🤔Before reading on: if a pod has multiple containers with different resource settings, can the pod be Guaranteed? Commit to your answer.

Concept: A pod's QoS class depends on all containers' resource settings combined.

If even one container in a pod has requests and limits that don't match, the whole pod cannot be Guaranteed. Kubernetes evaluates all containers together. This means careful resource setting per container is needed to achieve Guaranteed QoS for multi-container pods.

Result

Pod QoS class reflects the weakest container's resource configuration.

Knowing this prevents unexpected QoS downgrades in complex pods.

Under the Hood

Kubernetes calculates QoS class by inspecting each container's resource requests and limits in a pod. If all containers have equal requests and limits, the pod is Guaranteed. If requests exist but limits are higher, it's Burstable. If no requests or limits are set, it's BestEffort. The kubelet uses this classification to prioritize pods during scheduling and eviction, ensuring resource fairness and stability.

Why designed this way?

This design balances strict resource guarantees with flexibility. Guaranteed pods get strong protection for critical workloads. Burstable pods allow efficient resource use by permitting bursts. BestEffort pods maximize cluster utilization but accept eviction risk. Alternatives like static priority would be less flexible and harder to manage dynamically.

┌─────────────────────────────┐
│ Pod QoS Classification Flow │
├─────────────────────────────┤
│ For each container in pod:  │
│  Check requests and limits  │
│                             │
│ ┌─────────────────────────┐ │
│ │ All equal requests=limits│─┐
│ └─────────────────────────┘ │
│           Yes              │
│           ↓                │
│       Pod = Guaranteed     │
│           No               │
│           ↓                │
│ Requests set?              │
│   Yes → Pod = Burstable    │
│   No  → Pod = BestEffort   │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does setting only resource limits without requests make a pod Guaranteed? Commit yes or no.

Common Belief: If I set resource limits, my pod is Guaranteed because it has resource caps.

Reality: A pod is Guaranteed only if requests and limits are set and equal for all containers. Limits alone do not define QoS.

Why it matters: Misunderstanding this leads to pods being classified as Burstable or BestEffort, risking eviction when you expect strong guarantees.

Quick: Are BestEffort pods guaranteed any CPU or memory? Commit yes or no.

Common Belief: BestEffort pods still get some guaranteed CPU or memory from the node.

Reality: BestEffort pods have no resource requests or limits, so they get no guaranteed resources and are evicted first under pressure.

Why it matters: Assuming BestEffort pods have guarantees can cause critical workloads to fail unexpectedly.

Quick: Can a pod with multiple containers have mixed QoS classes? Commit yes or no.

Common Belief: Each container in a pod can have its own QoS class independently.

Reality: QoS is assigned at the pod level based on all containers combined, not per container.

Why it matters: Ignoring this can cause confusion when pods behave differently than expected under resource pressure.

Quick: Does Kubernetes always evict pods based on QoS class only? Commit yes or no.

Common Belief: Kubernetes evicts pods strictly by QoS class order every time.

Reality: Eviction also depends on node conditions, pod priority, and other factors; QoS is a key but not sole factor.

Why it matters: Overreliance on QoS alone can lead to surprises in eviction behavior.

Expert Zone

1

Guaranteed QoS requires exact equality of requests and limits for every resource (CPU and memory) in all containers, including init containers.

2

Burstable pods can still be evicted before Guaranteed pods even if they use less resources, because QoS is about guarantees, not actual usage.

3

Pod priority and QoS interact but are separate; a low-priority Guaranteed pod can be evicted before a high-priority Burstable pod under some conditions.

When NOT to use

Avoid relying solely on QoS classes for critical workload protection; use Pod Priority and Preemption for finer control. For strict resource isolation, consider using Kubernetes namespaces with ResourceQuotas or dedicated nodes.

Production Patterns

In production, Guaranteed QoS is used for critical system components like databases. Burstable is common for user-facing apps that can tolerate some resource variability. BestEffort is reserved for batch jobs or non-critical workloads that can be interrupted without impact.

Connections

Linux cgroups

QoS classes build on Linux cgroups resource limits and priorities.

Understanding cgroups helps grasp how Kubernetes enforces resource limits and prioritizes pods at the OS level.

Operating System Process Scheduling

Kubernetes QoS classes conceptually mirror OS process priority levels.

Knowing OS scheduling clarifies why Guaranteed pods get CPU preference similar to high-priority processes.

Traffic Prioritization in Networking

QoS in Kubernetes is similar to network QoS that prioritizes important data packets.

Recognizing this analogy helps understand how resource prioritization improves overall system performance and fairness.

Common Pitfalls

#1 Not setting resource requests and limits causes pods to be BestEffort unintentionally.

Wrong approach:

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: app
image: nginx

Correct approach:

apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: app
image: nginx
resources:
requests:
cpu: "100m"
memory: "200Mi"
limits:
cpu: "100m"
memory: "200Mi"

Root cause:

Beginners often skip resource settings, not realizing this defaults pods to BestEffort, risking eviction.

#2 Setting requests but no limits expecting Guaranteed QoS.

Wrong approach:

resources:
requests:
cpu: "100m"
memory: "200Mi"

Correct approach:

resources:
requests:
cpu: "100m"
memory: "200Mi"
limits:
cpu: "100m"
memory: "200Mi"

Root cause:

Misunderstanding that both requests and limits must be equal for Guaranteed class.

#3 Assuming pod QoS is determined per container, not per pod.

Wrong approach:

Container A: requests=limits=100m CPU
Container B: requests=50m CPU, limits=100m CPU
Assuming pod is Guaranteed

Correct approach:

Set both containers with equal requests and limits to achieve Guaranteed QoS for the pod.

Root cause:

Confusing container-level resource settings with pod-level QoS classification.

Key Takeaways

Kubernetes QoS classes prioritize pods based on resource requests and limits to manage cluster resources fairly.

Guaranteed pods have equal requests and limits for all containers, ensuring the highest resource protection.

Burstable pods have requests less than limits, allowing flexible resource use but lower eviction priority than Guaranteed.

BestEffort pods have no resource requests or limits and are the first to be evicted under resource pressure.

Understanding QoS classes helps design stable, efficient workloads and avoid unexpected pod evictions.

Practice

1. Which Kubernetes Quality of Service (QoS) class guarantees that a pod will always get the resources it requests?

easy

A. Burstable

B. Guaranteed

C. BestEffort

D. Reserved

Solution

1. Step 1: Understand QoS classes in Kubernetes

   There are three main QoS classes: Guaranteed, Burstable, and BestEffort. Guaranteed means the pod has resource requests equal to limits.

2. Step 2: Identify which class ensures resource guarantees

   Guaranteed pods always get the resources they request because requests and limits match exactly.

3. Final Answer:

   Guaranteed -> Option B

4. Quick Check:

   Guaranteed = full resource guarantee [OK]

Hint: Guaranteed means requests equal limits, so full resource guarantee [OK]

Common Mistakes:

• Confusing Burstable with Guaranteed
• Thinking BestEffort has resource guarantees
• Assuming Reserved is a QoS class

2. Which of the following pod resource specifications will result in a Burstable QoS class?

easy

A. resources:\n requests:\n cpu: '200m'\n memory: '128Mi'\n limits:\n cpu: '500m'\n memory: '256Mi'

B. resources:\n requests:\n cpu: '500m'\n memory: '256Mi'\n limits:\n cpu: '500m'\n memory: '256Mi'

C. resources:\n requests:\n cpu: '0'\n memory: '0'\n limits:\n cpu: '0'\n memory: '0'

D. resources: {}

Solution

1. Step 1: Review resource requests and limits for QoS classes

   Guaranteed requires requests equal to limits. Burstable requires requests less than limits. BestEffort has no requests or limits.

2. Step 2: Match the given specs to Burstable

   resources:\n requests:\n cpu: '200m'\n memory: '128Mi'\n limits:\n cpu: '500m'\n memory: '256Mi' has requests less than limits, so it is Burstable.

3. Final Answer:

   requests less than limits -> Option A

4. Quick Check:

   Burstable = requests < limits [OK]

Hint: Burstable means requests less than limits, not equal [OK]

Common Mistakes:

• Choosing equal requests and limits as Burstable
• Assuming empty resources means Burstable
• Confusing zero requests with BestEffort

3. Given this pod spec snippet, what QoS class will Kubernetes assign?

resources:
  requests:
    cpu: '100m'
    memory: '128Mi'
  limits:
    cpu: '100m'
    memory: '128Mi'

medium

A. Burstable

B. BestEffort

C. null

D. Guaranteed

Solution

1. Step 1: Compare requests and limits in the pod spec

   Requests and limits for both CPU and memory are equal (100m CPU and 128Mi memory).

2. Step 2: Determine QoS class based on equality

   When requests equal limits for all resources, Kubernetes assigns Guaranteed QoS.

3. Final Answer:

   Guaranteed -> Option D

4. Quick Check:

   Requests = Limits means Guaranteed [OK]

Hint: Equal requests and limits means Guaranteed QoS [OK]

Common Mistakes:

• Choosing Burstable when requests equal limits
• Thinking BestEffort applies with resource specs
• Selecting null as a QoS class

4. Given this pod spec snippet, what QoS class will Kubernetes assign?

resources:
  requests:
    cpu: '0'
    memory: '0'

medium

A. BestEffort

B. Burstable

C. Guaranteed

D. It will cause a syntax error

Solution

1. Step 1: Analyze the resource specification

   Requests are set to cpu: '0' and memory: '0', with no limits defined.

2. Step 2: Apply QoS classification rules

   Requests are specified but zero values are treated as no requests. No limits are defined. This qualifies as BestEffort, since no resource requests or limits are effectively set.

3. Final Answer:

   BestEffort -> Option A

4. Quick Check:

   No requests or limits means BestEffort [OK]

Hint: Zero requests with no limits -> BestEffort (not Burstable) [OK]

Common Mistakes:

• Thinking it causes a syntax error
• Assuming zero requests means BestEffort
• Believing it qualifies as Guaranteed

5. You want to ensure a pod gets guaranteed CPU and memory resources but also allow it to burst beyond the requested amount when available. Which resource configuration and QoS class combination achieves this?

hard

A. Set no requests or limits; QoS class BestEffort

B. Set requests equal to limits; QoS class Guaranteed

C. Set requests less than limits; QoS class Burstable

D. Set limits less than requests; QoS class Burstable

Solution

1. Step 1: Understand resource guarantees and bursting

   Guaranteed QoS requires requests equal to limits, which means no bursting beyond limits. Burstable allows requests less than limits, enabling bursting.

2. Step 2: Match configuration to desired behavior

   Setting requests less than limits gives minimum guaranteed resources with ability to burst, which is Burstable QoS.

3. Final Answer:

   Set requests less than limits; QoS class Burstable -> Option C

4. Quick Check:

   Burstable = guaranteed minimum + burst capacity [OK]

Hint: Burstable = requests less than limits for bursting [OK]

Common Mistakes:

• Choosing Guaranteed which disallows bursting
• Setting limits less than requests (invalid)
• Assuming BestEffort provides guarantees