Quality of Service classes (Guaranteed, Burstable, BestEffort) in Kubernetes - Commands & Configuration

Introduction

Kubernetes uses Quality of Service (QoS) classes to decide how to allocate resources like CPU and memory to containers. This helps keep important apps running smoothly even when the system is busy.

When you want to make sure a critical app always gets the resources it needs.

When you have apps that can use extra resources if available but can work with less.

When you run apps that do not need guaranteed resources and can be slowed down or stopped if needed.

When you want to control how Kubernetes handles resource shortages for different apps.

When you want to optimize resource use on a shared cluster with many apps.

Config File - pod-qos.yaml

pod-qos.yaml

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
spec:
  containers:
  - name: guaranteed-container
    image: nginx
    resources:
      requests:
        memory: "200Mi"
        cpu: "500m"
      limits:
        memory: "200Mi"
        cpu: "500m"
  - name: burstable-container
    image: nginx
    resources:
      requests:
        memory: "100Mi"
        cpu: "200m"
      limits:
        memory: "300Mi"
        cpu: "1"
  - name: besteffort-container
    image: nginx
    resources: {}

This file defines a Pod with three containers demonstrating each QoS class:

• Guaranteed: Requests and limits are equal for CPU and memory, so Kubernetes guarantees these resources.
• Burstable: Requests are less than limits, so the container can use extra resources if available but is not guaranteed.
• BestEffort: No requests or limits set, so this container gets resources only if nothing else needs them.

Commands

This command creates the Pod with three containers, each having different QoS classes to show how Kubernetes treats their resource needs.

Terminal

kubectl apply -f pod-qos.yaml

Expected Output

pod/qos-demo created

This command shows the overall QoS class of the Pod based on its containers' resource settings.

Terminal

kubectl get pods qos-demo -o jsonpath='{.status.qosClass}'

Expected Output

Burstable

→

-o jsonpath='{.status.qosClass}' - Extracts only the QoS class value from the Pod status

This command gives detailed information about the Pod, including resource requests, limits, and QoS classes for each container.

Terminal

kubectl describe pod qos-demo

Expected Output

Name:         qos-demo

Namespace:    default

Priority:     0

Node:         <node-name>/<node-ip>

Start Time:   <start-time>

Labels:       <none>

Annotations:  <none>

Status:       Running

QoS Class:    Burstable

Containers:

  guaranteed-container:

    Container ID:   docker://<id>

    Image:          nginx

    Limits:

      cpu:     500m

      memory:  200Mi

    Requests:

      cpu:     500m

      memory:  200Mi

    State:          Running

  burstable-container:

    Container ID:   docker://<id>

    Image:          nginx

    Limits:

      cpu:     1

      memory:  300Mi

    Requests:

      cpu:     200m

      memory:  100Mi

    State:          Running

  besteffort-container:

    Container ID:   docker://<id>

    Image:          nginx

    Limits:        <none>

    Requests:      <none>

    State:          Running

Conditions:

  Type              Status

  Initialized       True 

  Ready             True 

  ContainersReady   True 

  PodScheduled      True 

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes uses resource requests and limits to assign QoS classes that control how it prioritizes containers during resource shortages.

Common Mistakes

Setting resource limits but not requests for a container.

This causes the container to be classified as BestEffort, which means it gets the lowest priority and no guaranteed resources.

Always set both requests and limits to get Burstable or Guaranteed QoS classes.

Setting requests and limits to different values but expecting Guaranteed QoS.

Guaranteed QoS requires requests and limits to be exactly equal for all resources.

Set requests and limits to the same values for CPU and memory to get Guaranteed QoS.

Not setting any resource requests or limits.

This results in BestEffort QoS, which can cause the container to be killed first under resource pressure.

Set at least resource requests to avoid BestEffort QoS.

Summary

Create a Pod with containers having different resource requests and limits to see QoS classes in action.

Use 'kubectl get pods' with jsonpath to check the Pod's QoS class.

Use 'kubectl describe pod' to see detailed resource and QoS info for each container.

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