Requests म्हणजे container ला जे हमीदार दिले जाते (scheduling साठी वापरले जाते); limits म्हणजे तो जी कमाल मर्यादा ओलांडू शकत नाही (runtime ला अंमलात आणली जाते). एकत्रितपणे ते Pods कुठे ठेवले जातात, दबावाखाली ते कसे throttle किंवा kill होतात, आणि Pod ला कोणता Quality of Service (QoS) class मिळतो हे ठरवतात.
REQUEST → the amount RESERVED for the container. The SCHEDULER uses the sum of
requests to decide if a node has room. This is your guaranteed floor.
LIMIT → the MAX the container may use. Enforced at runtime:
CPU over limit → THROTTLED (slowed down, not killed)
memory over limit → OOM-KILLED (container terminated, then restarted)
spec:
containers:
- name: app
image: myapp:1.0
resources:
requests:
cpu: "250m" # एका core चा 0.25, हमीदार
memory: "256Mi"
limits:
cpu: "500m" # 0.5 core पर्यंत burst होऊ शकतो, मग throttled
memory: "512Mi" # हे ओलांडले → OOMKilled
Node has 4 CPU / 8Gi allocatable.
Scheduler sums the REQUESTS of Pods already placed; a new Pod fits only if its
requests still fit in what remains. (Limits are NOT used for placement.)
→ Set requests too low → node overcommitted, Pods fight for resources.
→ Set requests too high → wasted capacity, Pods stuck Pending (nothing fits).
Guaranteed → requests == limits for BOTH cpu & memory (every container)
→ last to be evicted (highest priority)
Burstable → has requests but they are < limits (or partially set)
→ evicted after BestEffort
BestEffort → no requests or limits at all
→ FIRST to be evicted when the node runs low on memory
kubectl describe pod app | grep -i qos # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods # प्रत्यक्ष CPU/memory वापर
kubectl describe node <node> # Allocated resources विरुद्ध capacity
✓ Always set memory requests = limits for predictable, OOM-safe behavior on critical apps
✓ Set CPU requests to the steady-state need; CPU limits are often left off to allow bursting
✓ Right-size from real usage (kubectl top / metrics) — not guesses
✓ Use LimitRange / ResourceQuota to enforce sane defaults per namespace
Requests आणि limits द्वारेच Kubernetes मर्यादित node resources न्याय्य व अंदाजाने वाटते, त्यामुळे हा फरक आणि त्याचे परिणाम समजून घेणे हे अत्यावश्यक performance व reliability ज्ञान आहे. मूळ अंतर्दृष्टी अशी की ते वेगवेगळ्या उद्देशांसाठी असतात: requests ही एक हमीदार राखीव जागा आहे जी scheduler Pods ठेवण्यासाठी वापरतो (node ला जागा आहे का ते ठरवण्यासाठी requests ची बेरीज करतो, limits दुर्लक्षून), तर limits ही runtime कमाल मर्यादा आहे जी प्रत्येक resource साठी वेगळ्या पद्धतीने अंमलात येते — CPU limit ओलांडल्यास तुम्ही throttled होता (मंदावता), पण memory limit ओलांडल्यास container OOM-killed होऊन restart होतो. requests चुकीच्या ठेवण्याचे दोन्ही बाजूंनी खरे परिणाम आहेत: फार कमी ठेवल्यास nodes overcommitted होतात व Pods एकमेकांची उपासमार करतात; फार जास्त ठेवल्यास capacity वाया जाते व काहीच बसत नसल्याने Pods Pending राहतात. तीन QoS classes — Guaranteed (requests व limits समान), Burstable (requests limits पेक्षा कमी), आणि BestEffort (काहीच सेट नाही) — memory दबावाखाली eviction क्रम ठरवतात, BestEffort प्रथम व Guaranteed शेवटी मारला जातो, जे critical workloads चे संरक्षण करण्यासाठी समजणे नेमके आवश्यक आहे. व्यावहारिक मार्गदर्शन जाणणे (critical apps साठी memory requests व limits समान ठेवा, kubectl top द्वारे खऱ्या वापरातून right-size करा, LimitRange/ResourceQuota ने defaults लागू करा) हे सिद्धांतातून योग्य capacity planning मध्ये रूपांतरित करते. खऱ्या clusters मध्ये resource चुकीचे configure करणे हे अस्थिरता, वाया गेलेला खर्च व Pending Pods यांचे सर्वांत सामान्य कारण आहे म्हणून, requests, limits व QoS वर प्रभुत्व मिळवणे हे कार्यक्षम, स्थिर Kubernetes workloads चालवण्यासाठी मूलभूत आहे.
सविस्तर उत्तरांसह IT मुलाखत प्रश्नांचे ग्रंथालय — Junior पासून Senior पर्यंत.
देणगी द्या