Requests वह है जो एक container को गारंटीशुदा मिलता है (scheduling के लिए उपयोग होता है); limits वह अधिकतम सीमा है जिसे वह पार नहीं कर सकता (runtime पर लागू)। मिलकर ये तय करते हैं कि Pods कहाँ रखे जाएँ, दबाव में उन्हें कैसे throttle या kill किया जाए, और किसी Pod को कौन-सी Quality of Service (QoS) श्रेणी मिले।
REQUEST → container के लिए RESERVE की गई मात्रा। SCHEDULER requests के योग का उपयोग यह
तय करने को करता है कि किसी node में जगह है या नहीं। यह आपकी गारंटीशुदा न्यूनतम है।
LIMIT → अधिकतम जो container उपयोग कर सकता है। runtime पर लागू:
CPU limit से ऊपर → THROTTLED (धीमा, मारा नहीं जाता)
memory limit से ऊपर → OOM-KILLED (container समाप्त, फिर restart)
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 में 4 CPU / 8Gi allocatable है।
Scheduler पहले से रखे Pods के REQUESTS जोड़ता है; एक नया Pod तभी फिट होता है जब उसके
requests बचे हुए में समाते हों। (limits placement के लिए उपयोग नहीं होते।)
→ requests बहुत कम सेट करें → node overcommitted, Pods resources के लिए लड़ते हैं।
→ requests बहुत अधिक सेट करें → क्षमता बर्बाद, Pods Pending में अटके (कुछ फिट नहीं होता)।
Guaranteed → cpu व memory DONON के लिए requests == limits (हर container)
→ सबसे आख़िर में evict (उच्चतम प्राथमिकता)
Burstable → requests हैं पर वे < limits हैं (या आंशिक रूप से सेट)
→ BestEffort के बाद evict
BestEffort → कोई requests या limits ही नहीं
→ जब node की memory कम पड़ती है तो सबसे PEHLE evict
kubectl describe pod app | grep -i qos # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods # असली CPU/memory उपयोग
kubectl describe node <node> # आवंटित resources बनाम capacity
✓ महत्वपूर्ण apps पर पूर्वानुमेय, OOM-सुरक्षित व्यवहार हेतु हमेशा memory requests = limits सेट करें
✓ CPU requests को steady-state ज़रूरत पर सेट करें; bursting हेतु CPU limits अक्सर छोड़ दिए जाते हैं
✓ असली उपयोग से right-size करें (kubectl top / metrics) — अनुमान से नहीं
✓ प्रति namespace समझदार defaults लागू करने हेतु LimitRange / ResourceQuota उपयोग करें
Requests और limits ही वह तरीका हैं जिससे Kubernetes सीमित node resources को निष्पक्ष और पूर्वानुमेय ढंग से साझा करता है, इसलिए इस अंतर और इसके परिणामों को समझना आवश्यक performance और विश्वसनीयता ज्ञान है। मूल अंतर्दृष्टि यह है कि वे अलग उद्देश्य पूरे करते हैं: requests एक गारंटीशुदा आरक्षण है जिसका उपयोग scheduler Pods रखने के लिए करता है (यह तय करने को requests जोड़ता है कि node में जगह है या नहीं, limits की अनदेखी करते हुए), जबकि limits एक runtime सीमा है जो प्रति resource अलग ढंग से लागू होती है — CPU limit पार करने पर आप throttled (धीमे) होते हैं, पर memory limit पार करने पर container OOM-killed होकर restart होता है। requests को ग़लत करने की दोनों ओर असली कीमत है: बहुत कम तो nodes overcommitted हो जाते हैं और Pods एक-दूसरे को भूखा रखते हैं; बहुत अधिक तो क्षमता बर्बाद होती है जबकि Pods Pending बैठे रहते हैं क्योंकि कुछ फिट नहीं होता। तीन QoS श्रेणियाँ — Guaranteed (requests बराबर limits), Burstable (requests limits से कम), और BestEffort (कुछ सेट नहीं) — memory दबाव में eviction क्रम तय करती हैं, BestEffort सबसे पहले और Guaranteed सबसे आख़िर में मारा जाता है, जो ठीक वही है जो आपको महत्वपूर्ण workloads की रक्षा हेतु समझना ज़रूरी है। व्यावहारिक मार्गदर्शन जानना (महत्वपूर्ण apps के लिए memory requests को limits के बराबर सेट करें, kubectl top से असली उपयोग के अनुसार right-size करें, LimitRange/ResourceQuota से defaults लागू करें) इसे सिद्धांत से ठोस capacity planning में बदल देता है। चूँकि resource की ग़लत configuration असली clusters में अस्थिरता, बर्बाद ख़र्च और Pending Pods के सबसे आम कारणों में से एक है, requests, limits और QoS में महारत हासिल करना कुशल, स्थिर Kubernetes workloads चलाने की नींव है।
विस्तृत उत्तरों के साथ IT इंटरव्यू प्रश्नों की एक लाइब्रेरी — जूनियर से सीनियर तक।
दान करें