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

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

🍛 धडा 08 — Requests आणि limits: जेवणाचे वाटे

📍 तुम्ही इथे आहात: 13 पैकी धडा 08 · मागचा: lesson-07-health-probes · पुढचा: lesson-09-autoscaling

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

धडे 01–07, आणि: resource requests आणि limits — CPU आणि memory न्याय्य पद्धतीने कसे वाटले जातात, आणि pod कोणत्या machine वर जाईल हे Kubernetes कसे ठरवतो. खरी file:

k8s/deployment.yaml — resources: block

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

शाळेचे उपाहारगृह 🍛. जेवणाची वेळ न्याय्य ठेवणारे दोन नियम:

वचन दिलेले ताट — प्रत्येक मुलाला एका ताटभर जेवणाची हमी असते. मुलांना आत घेण्याआधी स्वयंपाकी ताटे मोजतात: 30 ताटे, 30 मुले, दार बंद. ज्या उपाहारगृहात जेवायला मिळणार नाही तिथे कोणीच जात नाही. → हा request: एक आरक्षण. Kubernetes pod फक्त अशाच machine वर ठेवतो जिथे अजून तितका CPU/RAM शिल्लक आहे.
पुन्हा वाढण्याची मर्यादा — भुकेले मूल पुन्हा वाढून घेऊ शकते, पण जास्तीत जास्त 2 जादा पळ्या. इतरांना उपाशी ठेवून कोणीही संपूर्ण पातेले रिकामे करू शकत नाही. → हा limit: pod खरोखर किती वापरू शकतो त्यावरची पक्की मर्यादा.

मात्र मर्यादा गाठल्यावर वेगवेगळे पदार्थ वेगवेगळे वागतात:

CPU म्हणजे सूप 🍲 — मर्यादा गाठली तर तुम्हाला फक्त हळू वाढले जाते (throttled). त्रासदायक, पण जीवघेणे नाही.
Memory म्हणजे तुमचे पोट 🫃 — इथे "हळू खाणे" असे काही नाही. Pod ने limit पेक्षा जास्त memory वापरण्याचा प्रयत्न केला तर तो जागीच मारला जातो (प्रसिद्ध OOMKilled).

🗺️ आकृती

flowchart TB
    subgraph node["🖥️ Node - machine with 2 CPU, 4Gi RAM"]
        subgraph p1["🪑 school-api pod"]
            r1["request: 100m CPU, 128Mi<br/>= reserved seat"]
            l1["limit: 500m CPU, 256Mi<br/>= max scoops"]
        end
        subgraph p2["🪑 school-analytics pod"]
            r2["request: 100m, 128Mi"]
            l2["limit: 500m, 256Mi"]
        end
        free["🟩 unreserved space<br/>scheduler can place more pods here"]
    end
    sched["📋 Scheduler - the cook counting plates"] -->|"places pods only where<br/>requests still fit"| node

❓ काय

requests — pod ला ज्याची हमी आहे ते. Scheduler node निवडताना हे वापरतो ("या machine वर अजून 100m CPU + 128Mi आरक्षित न केलेले आहे का?").
limits — pod ने कधीच ओलांडू नये ते. CPU limit वर गेला → throttled; memory limit वर गेली → container OOMKilled आणि restart.
एकके: 100m = 100 millicores = 0.1 CPU core. 128Mi = 128 mebibytes.
हेच आकडे HPA ची मोजपट्टी (धडा 09) पण आहेत: "70% CPU" म्हणजे request च्या 70%, म्हणजे आपल्या 100m पैकी 70m.

🤔 का

Requests नसतील तर scheduler डोळ्यावर पट्टी बांधून उपाहारगृह भरतो — 30 ताटांच्या खोलीत 50 मुले, आणि सगळ्यांचे जेवण बिघडते (nodes वर ओझे वाढते, कोणतेही pods मरतात). Limits नसतील तर एकच गळके app संपूर्ण machine खाऊन टाकते आणि त्याच्या निर्दोष शेजाऱ्यांनाही सोबत पाडते. Requests + limits = न्याय्य वाटणी + अंदाज करता येणारी जागा + फक्त एका pod इतकी नुकसानाची सीमा. प्रत्येक production cluster review ची सुरुवात "तुमच्या pods वर resources set आहेत का?" याने होते.

🔧 कसे (या repo मध्ये)

k8s/deployment.yaml मध्ये (analytics च्या file मध्येही तसेच):

resources:
  requests:
    cpu: 100m        # reserve 0.1 core  → scheduler's math
    memory: 128Mi    # reserve 128Mi
  limits:
    cpu: 500m        # may burst to half a core, then throttled
    memory: 256Mi    # touch 257Mi → OOMKilled 💀

replicas: 2 सह, हे app एकूण 200m CPU + 256Mi आरक्षित करते — scheduler दिवसभर प्रत्येक node वरच्या प्रत्येक pod साठी हे गणित करतो.

🧪 करून पाहा

# What did the scheduler reserve on your node?
kubectl describe node | grep -A8 "Allocated resources"

# Live usage vs those numbers (needs metrics-server):
kubectl -n school top pods

# See an OOMKill with your own eyes (safe — it's just one test pod):
kubectl -n school run greedy --restart=Never --image=polinux/stress \
  --overrides='{"spec":{"containers":[{"name":"greedy","image":"polinux/stress",
    "resources":{"limits":{"memory":"50Mi"}},
    "args":["--vm","1","--vm-bytes","200M","--vm-hang","0"],"command":["stress"]}]}}'
kubectl -n school get pod greedy -w        # → OOMKilled 💀 (Ctrl+C, then clean up:)
kubectl -n school delete pod greedy

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

kubectl top pods · kubectl describe node (Allocated resources)

🔗 यावर आधारित: 🪪 AWS L08 (types आणि sizes — तुम्ही आरक्षित करता ते ताट)

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

kubectl top pods वापर दाखवते; memory limit च्या पलीकडे ढकला → pod OOMKilled होऊन restart होतो; CPU ढकला → तो हळू होतो, कधीच मरत नाही.

🧹 साफसफाई

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

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

requests अजिबात नसणे — BestEffort, सर्वात आधी evict होतो (L23)
limits requests पेक्षा खूप जास्त — over-commit, ज्यामुळे शेजारी OOMKilled होतो

⏭️ पुढे

Requests हीच आत्तापर्यंतच्या सर्वात भारी युक्तीची मोजपट्टी आहे: गर्दीच्या दिवशी आपोआप वाढणारे pods — HorizontalPodAutoscaler.

git checkout lesson-09-autoscaling

🍛 Lesson 08 — Requests & limits: lunch portions

📍 You are here: Lesson 08 of 13 · Previous: lesson-07-health-probes · Next: lesson-09-autoscaling

📦 What's in this branch

Lessons 01–07, plus: resource requests and limits — how CPU and memory are shared fairly, and how Kubernetes decides which machine a pod lands on. Real file:

k8s/deployment.yaml — the resources: block

🧒 Explain like I'm 5

School canteen 🍛. Two rules keep lunchtime fair:

The promised plate — every kid is guaranteed one plate of food. The cook counts plates before letting kids in: 30 plates, 30 kids, door closed. Nobody enters a canteen that can't feed them. → That's the request: a reservation. Kubernetes only places a pod on a machine that still has that much CPU/RAM spare.
The seconds cap — a hungry kid may take seconds, but at most 2 extra scoops. No kid may empty the whole pot while others starve. → That's the limit: a hard cap on what the pod may actually use.

Different foods behave differently when you hit the cap, though:

CPU is like soup 🍲 — if you hit the cap, you're just served slower (throttled). Annoying, not deadly.
Memory is like your stomach 🫃 — there is no "eating slower". If a pod tries to use more memory than its limit, it's killed on the spot (the famous OOMKilled).

🗺️ Diagram

flowchart TB
    subgraph node["🖥️ Node - machine with 2 CPU, 4Gi RAM"]
        subgraph p1["🪑 school-api pod"]
            r1["request: 100m CPU, 128Mi<br/>= reserved seat"]
            l1["limit: 500m CPU, 256Mi<br/>= max scoops"]
        end
        subgraph p2["🪑 school-analytics pod"]
            r2["request: 100m, 128Mi"]
            l2["limit: 500m, 256Mi"]
        end
        free["🟩 unreserved space<br/>scheduler can place more pods here"]
    end
    sched["📋 Scheduler - the cook counting plates"] -->|"places pods only where<br/>requests still fit"| node

❓ What

requests — what the pod is guaranteed. Used by the scheduler to pick a node ("does this machine still have 100m CPU + 128Mi unreserved?").
limits — what the pod may never exceed. CPU over limit → throttled; memory over limit → container OOMKilled and restarted.
Units: 100m = 100 millicores = 0.1 CPU core. 128Mi = 128 mebibytes.
These numbers are also the HPA's yardstick (lesson 09): "70% CPU" means 70% of the request, i.e. 70m of our 100m.

🤔 Why

Without requests, the scheduler is packing a canteen blindfolded — 50 kids in a 30-plate room, and everyone's lunch is ruined (nodes overload, random pods die). Without limits, one leaky app eats a whole machine and takes its innocent neighbors down with it. Requests + limits = fair sharing + predictable placement + a blast radius of exactly one pod. Every production cluster review starts with "do your pods have resources set?".

🔧 How (in this repo)

In k8s/deployment.yaml (same in the analytics one):

resources:
  requests:
    cpu: 100m        # reserve 0.1 core  → scheduler's math
    memory: 128Mi    # reserve 128Mi
  limits:
    cpu: 500m        # may burst to half a core, then throttled
    memory: 256Mi    # touch 257Mi → OOMKilled 💀

With replicas: 2, this app reserves 200m CPU + 256Mi total — the scheduler does this arithmetic for every pod on every node, all day long.

🧪 Try it

# What did the scheduler reserve on your node?
kubectl describe node | grep -A8 "Allocated resources"

# Live usage vs those numbers (needs metrics-server):
kubectl -n school top pods

# See an OOMKill with your own eyes (safe — it's just one test pod):
kubectl -n school run greedy --restart=Never --image=polinux/stress \
  --overrides='{"spec":{"containers":[{"name":"greedy","image":"polinux/stress",
    "resources":{"limits":{"memory":"50Mi"}},
    "args":["--vm","1","--vm-bytes","200M","--vm-hang","0"],"command":["stress"]}]}}'
kubectl -n school get pod greedy -w        # → OOMKilled 💀 (Ctrl+C, then clean up:)
kubectl -n school delete pod greedy

🔧 kubectl for this lesson

kubectl top pods · kubectl describe node (Allocated resources)

🔗 Builds on: 🪪 AWS L08 (types & sizes — the plate you reserve)

✅ Verify — what you should see

kubectl top pods shows usage; push memory past the limit → the pod is OOMKilled and restarted; push CPU → it slows, never dies.

🧹 Clean up

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

⚠️ Common mistakes

no requests at all — BestEffort, first to be evicted (L23)
limits far above requests — over-commit that OOMKills the neighbour

⏭️ Next

Requests are the yardstick for the coolest trick yet: pods that multiply on busy days all by themselves — the HorizontalPodAutoscaler.

git checkout lesson-09-autoscaling

← Previoushealth probes Next →autoscaling

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