0
0
Kubernetesdevops~10 mins

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

Choose your learning style9 modes available
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
StepPod Resource RequestsPod Resource LimitsQoS Class DeterminedReason
1CPU=100m, Memory=100MiCPU=100m, Memory=100MiGuaranteedRequests equal limits for all resources
2CPU=100m, Memory=100MiCPU=200m, Memory=150MiBurstableRequests set but limits higher than requests
3No requestsNo limitsBestEffortNo resource requests or limits set
4CPU=100mNo limitsBurstableRequests set but no limits
5No requestsCPU=100mBurstableLimits set but no requests
6---End of evaluation
💡 All pod resource specs evaluated; QoS class assigned based on rules.
Status Tracker
VariableStartAfter 1After 2After 3After 4After 5Final
Pod CPU RequestsNone100m100mNone100mNoneVaries per step
Pod CPU LimitsNone100m200mNoneNone100mVaries per step
Pod Memory RequestsNone100Mi100MiNoneNoneNoneVaries per step
Pod Memory LimitsNone100Mi150MiNoneNoneNoneVaries per step
QoS ClassNoneGuaranteedBurstableBestEffortBurstableBurstableVaries 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
Test your understanding
Look at the execution_table, what QoS class is assigned when CPU and Memory requests equal their limits?
AGuaranteed
BBurstable
CBestEffort
DNo 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?
AStep 5
BStep 2
CStep 3
DStep 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?
AIt remains Guaranteed
BIt becomes Burstable
CIt becomes BestEffort
DIt 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.