Quality of Service classes (Guaranteed, Burstable, BestEffort) in Kubernetes - Step-by-Step Execution

Process Flow - Quality of Service classes (Guaranteed, Burstable, BestEffort)

Pod Spec with Resources

↓

Check: Are requests and limits set for CPU and Memory?

↓

Guaranteed

↓

Pod Scheduling & Eviction Priority

↓

Pod Runs with QoS Class

Kubernetes assigns a QoS class to each pod based on resource requests and limits to decide scheduling and eviction priority.

Execution Sample

Kubernetes

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

This pod spec sets equal requests and limits for CPU and memory, so Kubernetes assigns it the Guaranteed QoS class.

Process Table

Step	Pod Resource Requests	Pod Resource Limits	QoS Class Determined	Reason
1	CPU=100m, Memory=100Mi	CPU=100m, Memory=100Mi	Guaranteed	Requests equal limits for all resources
2	CPU=100m, Memory=100Mi	CPU=200m, Memory=150Mi	Burstable	Requests set but limits higher than requests
3	No requests	No limits	BestEffort	No resource requests or limits set
4	CPU=100m	No limits	Burstable	Requests set but no limits
5	No requests	CPU=100m	Burstable	Limits set but no requests
6	-	-	-	End of evaluation

💡 All pod resource specs evaluated; QoS class assigned based on rules.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	Final
Pod CPU Requests	None	100m	100m	None	100m	None	Varies per step
Pod CPU Limits	None	100m	200m	None	None	100m	Varies per step
Pod Memory Requests	None	100Mi	100Mi	None	None	None	Varies per step
Pod Memory Limits	None	100Mi	150Mi	None	None	None	Varies per step
QoS Class	None	Guaranteed	Burstable	BestEffort	Burstable	Burstable	Varies per step

Key Moments - 3 Insights

Why does a pod with no resource requests or limits get BestEffort QoS?

Because Kubernetes treats pods without any resource requests or limits as lowest priority, assigning BestEffort as shown in execution_table row 3.

What makes a pod Burstable instead of Guaranteed?

If resource requests are set but limits are higher or missing, the pod is Burstable, as in rows 2, 4, and 5 of the execution_table.

Can a pod have requests but no limits and still be Burstable?

Yes, having requests without limits results in Burstable QoS, demonstrated in execution_table row 4.

Visual Quiz - 3 Questions

Look at the execution_table, what QoS class is assigned when CPU and Memory requests equal their limits?

A Guaranteed

B Burstable

C BestEffort

D No QoS assigned

💡 Hint

Refer to execution_table row 1 where requests equal limits.

At which step in the execution_table does the pod get BestEffort QoS?

A Step 5

B Step 2

C Step 3

D Step 1

💡 Hint

Check the QoS Class column for BestEffort in the execution_table.

If a pod has CPU requests but no limits, how does the QoS class change compared to having equal requests and limits?

A It remains Guaranteed

B It becomes Burstable

C It becomes BestEffort

D It cannot run

💡 Hint

See execution_table rows 1 and 4 for comparison.

Concept Snapshot

Kubernetes QoS classes:
- Guaranteed: requests = limits for CPU & memory
- Burstable: requests set, limits higher or missing
- BestEffort: no requests or limits
QoS affects pod scheduling and eviction priority.

Full Transcript

In Kubernetes, each pod is assigned a Quality of Service (QoS) class based on its resource requests and limits. If a pod sets equal CPU and memory requests and limits, it is classified as Guaranteed, giving it the highest priority. If requests are set but limits are higher or missing, the pod is Burstable, with medium priority. If no requests or limits are set, the pod is BestEffort, with the lowest priority. This classification helps Kubernetes decide which pods to schedule first and which to evict under resource pressure.

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