Quality of Service classes (Guaranteed, Burstable, BestEffort) in Kubernetes - Mini Project: Build & Apply

Quality of Service classes (Guaranteed, Burstable, BestEffort)

📖 Scenario: You are managing a Kubernetes cluster that runs different applications. Some apps need guaranteed resources, some can burst when needed, and some can use leftover resources. You want to learn how to set Quality of Service (QoS) classes for your pods to control resource allocation.

🎯 Goal: Learn how to create Kubernetes pod YAML files with resource requests and limits to get different QoS classes: Guaranteed, Burstable, and BestEffort.

📋 What You'll Learn

Create a pod YAML with resource requests and limits for CPU and memory

Add resource requests only to create Burstable QoS

Create a pod YAML without any resource requests or limits for BestEffort QoS

Use kubectl to check the QoS class of pods

💡 Why This Matters

🌍 Real World

Setting QoS classes helps Kubernetes decide which pods get resources first and which pods can be evicted when the cluster is busy.

💼 Career

Understanding QoS classes is important for Kubernetes administrators and DevOps engineers to manage resource allocation and ensure application reliability.

1

Create a pod YAML with resource requests and limits for Guaranteed QoS

Create a pod YAML file named guaranteed-pod.yaml with a single container named app. Set both requests and limits for cpu to 500m and memory to 256Mi under resources. Use the image nginx. This will create a pod with Guaranteed QoS class.

Kubernetes

# Create guaranteed-pod.yaml with requests and limits for cpu and memory
# Your code here

Hint

Remember to set both requests and limits with the same values for CPU and memory to get Guaranteed QoS.

2

Create a pod YAML with resource requests only for Burstable QoS

Create a pod YAML file named burstable-pod.yaml with a single container named app. Set only requests for cpu to 250m and memory to 128Mi under resources. Do not set any limits. Use the image nginx. This will create a pod with Burstable QoS class.

Kubernetes

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

# Create burstable-pod.yaml with requests only for cpu and memory
# Your code here

Hint

Set only requests without limits to get Burstable QoS.

3

Create a pod YAML without resource requests or limits for BestEffort QoS

Create a pod YAML file named besteffort-pod.yaml with a single container named app. Do not set any resources section. Use the image nginx. This will create a pod with BestEffort QoS class.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"
---
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "250m"
        memory: "128Mi"

# Create besteffort-pod.yaml without resources section
# Your code here

Hint

Do not include a resources section to get BestEffort QoS.

4

Check the QoS class of the pods using kubectl

Run the command kubectl get pods guaranteed-pod burstable-pod besteffort-pod -o jsonpath='{range .items[*]}{.metadata.name}: {.status.qosClass}\n{end}' to display the QoS class of each pod.

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: guaranteed-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "500m"
        memory: "256Mi"
      limits:
        cpu: "500m"
        memory: "256Mi"
---
apiVersion: v1
kind: Pod
metadata:
  name: burstable-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        cpu: "250m"
        memory: "128Mi"
---
apiVersion: v1
kind: Pod
metadata:
  name: besteffort-pod
spec:
  containers:
  - name: app
    image: nginx

# Run kubectl command to show QoS classes
# Your code here

Hint

Use the exact kubectl get pods command with -o jsonpath to see the QoS classes.

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