🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🍽️ धडा 23 — QoS classes आणि evictions: जेवण कमी पडले की कोण जाते

📍 तुम्ही इथे आहात: धडा 23 / 26 · मागील: lesson-22-statefulsets · पुढील: lesson-24-cluster-upgrades

📦 या ब्रँचमध्ये काय आहे

आधीचे सगळे, आणि प्रत्येक pod नकळत आधीच ज्या उतरंडीत आहे ती — QoS classes — आणि बाकावरची memory संपली की काय होते: evictions.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

धडा 08 च्या कॅन्टीनमध्ये वचन दिलेली ताटे (requests) आणि वाढप्याची मर्यादा (limits) होती. आता तो भाग, ज्याबद्दल जेवण खरोखर संपेपर्यंत कोणीच बोलत नाही: स्वयंपाकघर मुलांना क्रमांक देते. 🍽️

Guaranteed 🥇 — ज्या मुलांचे वचन त्यांच्या मर्यादेइतकेच आहे (requests == limits, CPU आणि memory दोन्ही). ते किती खातील ते स्वयंपाकघराला नेमके माहीत असते. त्यांना सर्वात शेवटी जायला सांगितले जाते.
Burstable 🥈 — एक वचन, आणि पुन्हा वाढून घेण्याची परवानगी (requests < limits). आपले school-api pods इथे राहतात.
BestEffort 🥉 — कोणतेही वचन न घेता आत आले (requests नाहीत, limits नाहीत). जे पडलेले असेल ते खातात… आणि कोठार कमी पडले की त्यांना सर्वात आधी जायला सांगितले जाते. resources शिवायचा प्रत्येक kubectl run यांपैकी एक बनवतो!

बाकावरची memory कमी पडली की (node pressure), kubelet evict करायला सुरुवात करतो: आधी BestEffort, मग वचनापेक्षा जास्त खाणारे Burstable, शेवटी Guaranteed. Eviction बऱ्यापैकी सभ्य असते (pod दुसरीकडे reschedule होतो — धडा 03 चा monitor ते सांभाळतो); त्याचा असभ्य चुलत भाऊ म्हणजे तात्काळ होणारा OOMKill (धडा 08), जेव्हा एखादा container स्वतःची मर्यादा ओलांडतो.

VIP passes सुद्धा असतात: PriorityClasses — system pods कडे system-node-critical असतो, म्हणजे शाळेच्या स्वतःच्या कर्मचाऱ्यांना विद्यार्थ्यांच्या आधी कधीच जायला सांगितले जात नाही.

🗺️ आकृती

flowchart TB
    pressure["🖥️ desk under memory pressure<br/>kubelet must free space"]
    be["🥉 BestEffort<br/>no requests/limits<br/>EVICTED FIRST"]
    bu["🥈 Burstable<br/>requests < limits<br/>next — biggest over-promise first"]
    g["🥇 Guaranteed<br/>requests == limits<br/>evicted last"]
    sys["👮 PriorityClass: system-critical<br/>the school's own staff — basically never"]
    pressure -->|"1"| be
    pressure -->|"2"| bu
    pressure -->|"3"| g
    pressure -.->|"4"| sys
    be -.->|"rescheduled elsewhere<br/>by the monitor (L03)"| be

❓ काय

QoS गणना करून ठरते, जाहीर केली जात नाही — requests/limits (L08) ठरवा आणि class आपोआप येतो. तपासा: kubectl get pod X -o jsonpath='{.status.qosClass}'.
Eviction ≠ OOMKill: eviction = दबावाखालचा node मोकळा करणारा kubelet (pod status Evicted, reschedule होतो); OOMKill = एका container ची स्वतःची limit लागू करणारा kernel (exit 137, जागीच restart).
दबावाखालचा क्रम: BestEffort → Burstable (requests पेक्षा सर्वात जास्त वापर असलेले आधी) → Guaranteed; बरोबरी सोडवताना PriorityClass QoS पेक्षा वरचढ.
व्यवहारातली भूमिका: databases/महत्त्वाचे एकटे pods → Guaranteed; साधी apps → प्रामाणिक Burstable; BestEffort → production मध्ये कधीच नाही (तो पहिला बळी आणि L08 मधल्या scheduler च्या हिशोबाला अदृश्य).

🤔 का

"गर्दीच्या वेळी कोणताही pod नाहीसा झाला" म्हणजे हाच धडा, दर वेळी. QoS हा धडा 08 चा हरवलेला दुसरा अर्धा भागसुद्धा आहे: requests फक्त pods ठेवत नाहीत — परिस्थिती तंग झाल्यावर त्या टिकण्याचा क्रम असतात. प्रामाणिक requests ठरवण्यात घालवलेली पाच मिनिटे सर्वात वाईट दिवशी अंदाज बांधता येणारे वर्तन मिळवून देतात.

🧪 करून पाहा

# what class are OUR pods? (requests<limits → Burstable)
kubectl -n school get pods -o custom-columns='NAME:.metadata.name,QOS:.status.qosClass'

# make one of each and compare:
kubectl -n school run best --image=busybox -- sleep 3600
kubectl -n school run guar --image=busybox \
  --overrides='{"spec":{"containers":[{"name":"guar","image":"busybox","command":["sleep","3600"],
    "resources":{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"50m","memory":"64Mi"}}}]}}'
kubectl -n school get pods best guar -o custom-columns='NAME:.metadata.name,QOS:.status.qosClass'
# best → BestEffort 🥉 · guar → Guaranteed 🥇

kubectl -n school delete pod best guar
# (real evictions need real node pressure — don't simulate on your laptop;
#  instead read any prod cluster's story: kubectl get events -A | grep -i evict)

🔧 या धड्यासाठी kubectl

kubectl get pod -o jsonpath · kubectl describe node (Conditions: MemoryPressure)

🔗 यावर आधारित: 🪪 AWS L08 (ताट राखून ठेवा)

✅ तपासा — तुम्हाला काय दिसले पाहिजे

kubectl get pod POD -o jsonpath='{.status.qosClass}' Guaranteed / Burstable / BestEffort छापते; दबावाखाली BestEffort pod सर्वात आधी evict होतो.

🧹 साफसफाई

local cluster: kubectl delete -f k8s/ (किंवा तुम्ही apply केलेली file) — EKS वर चालू राहिलेल्या कशाचेही तासाप्रमाणे बिल येते

⚠️ नेहमीच्या चुका

requests नसलेले महत्त्वाचे pods — BestEffort, सर्वात आधी evict
प्रत्येक गोष्टीवर PriorityClass — मग कशालाच प्राधान्य नसते

⏭️ पुढे

शाळा चालू ठेवून वर्गखोल्यांचे नूतनीकरण: cluster upgrades — जिथे cordon, drain, आणि धडा 15 चे PDBs अखेर एकत्र काम करतात.

git checkout lesson-24-cluster-upgrades

🍽️ Lesson 23 — QoS classes & evictions: who leaves when lunch runs short

📍 You are here: Lesson 23 of 26 · Previous: lesson-22-statefulsets · Next: lesson-24-cluster-upgrades

📦 What's in this branch

Everything before, plus the pecking order every pod is already in without knowing it — QoS classes — and what happens when a desk runs out of memory: evictions.

🧒 Explain like I'm 5

Lesson 08's canteen had promised plates (requests) and portion caps (limits). Here's the part nobody mentions until the food actually runs out: the kitchen ranks the kids. 🍽️

Guaranteed 🥇 — kids whose promise EQUALS their cap (requests == limits, both CPU & memory). The kitchen knows exactly what they'll eat. Asked to leave last.
Burstable 🥈 — a promise, plus permission for seconds (requests < limits). Our school-api pods live here.
BestEffort 🥉 — walked in with no promise at all (no requests, no limits). Eats whatever's lying around… and when the pantry runs low, they're asked to leave first. Every kubectl run without resources makes one of these!

When a desk runs low on memory (node pressure), the kubelet starts evicting: BestEffort first, then Burstable eating over its promise, Guaranteed last. Eviction is polite-ish (pod rescheduled elsewhere — lesson 03's monitor handles it); the impolite cousin is the instant OOMKill (lesson 08) when one container bursts past its own cap.

VIP passes exist too: PriorityClasses — system pods carry system-node-critical so the school's own staff is never asked to leave before the students.

🗺️ Diagram

flowchart TB
    pressure["🖥️ desk under memory pressure<br/>kubelet must free space"]
    be["🥉 BestEffort<br/>no requests/limits<br/>EVICTED FIRST"]
    bu["🥈 Burstable<br/>requests < limits<br/>next — biggest over-promise first"]
    g["🥇 Guaranteed<br/>requests == limits<br/>evicted last"]
    sys["👮 PriorityClass: system-critical<br/>the school's own staff — basically never"]
    pressure -->|"1"| be
    pressure -->|"2"| bu
    pressure -->|"3"| g
    pressure -.->|"4"| sys
    be -.->|"rescheduled elsewhere<br/>by the monitor (L03)"| be

❓ What

QoS is computed, not declared — set requests/limits (L08) and the class follows. Check: kubectl get pod X -o jsonpath='{.status.qosClass}'.
Eviction ≠ OOMKill: eviction = kubelet freeing a node under pressure (pod status Evicted, rescheduled); OOMKill = kernel enforcing one container's own limit (exit 137, restarts in place).
Order under pressure: BestEffort → Burstable (usage furthest above requests first) → Guaranteed; PriorityClass outranks QoS for the tie-breaks.
Practical stance: databases/critical singletons → Guaranteed; normal apps → honest Burstable; BestEffort → never in production (it's the first sacrifice AND invisible to the scheduler's math from L08).

🤔 Why

"Random pod disappeared at peak traffic" is this lesson, every time. QoS is also lesson 08's missing second half: requests don't just place pods — they're the survival ranking when things get tight. Five minutes spent setting honest requests buys you predictable behavior on the worst day.

🧪 Try it

# what class are OUR pods? (requests<limits → Burstable)
kubectl -n school get pods -o custom-columns='NAME:.metadata.name,QOS:.status.qosClass'

# make one of each and compare:
kubectl -n school run best --image=busybox -- sleep 3600
kubectl -n school run guar --image=busybox \
  --overrides='{"spec":{"containers":[{"name":"guar","image":"busybox","command":["sleep","3600"],
    "resources":{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"50m","memory":"64Mi"}}}]}}'
kubectl -n school get pods best guar -o custom-columns='NAME:.metadata.name,QOS:.status.qosClass'
# best → BestEffort 🥉 · guar → Guaranteed 🥇

kubectl -n school delete pod best guar
# (real evictions need real node pressure — don't simulate on your laptop;
#  instead read any prod cluster's story: kubectl get events -A | grep -i evict)

🔧 kubectl for this lesson

kubectl get pod -o jsonpath · kubectl describe node (Conditions: MemoryPressure)

🔗 Builds on: 🪪 AWS L08 (reserve the plate)

✅ Verify — what you should see

kubectl get pod POD -o jsonpath='{.status.qosClass}' prints Guaranteed / Burstable / BestEffort; under pressure the BestEffort pod is evicted first.

🧹 Clean up

local cluster: kubectl delete -f k8s/ (or the file you applied) — on EKS, anything left running bills by the hour

⚠️ Common mistakes

important pods with no requests — BestEffort, evicted first
a PriorityClass on everything — then nothing is prioritized

⏭️ Next

Renovating classrooms while school stays open: cluster upgrades — where cordon, drain, and lesson 15's PDBs finally perform together.

git checkout lesson-24-cluster-upgrades

← Previousstatefulsets Next →cluster upgrades

This page is the lesson's README from the lesson-23-qos-evictions branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.