Request भनेको container लाई ग्यारेन्टी गरिएको (scheduling का लागि प्रयोग हुने); limit भनेको यसले नाघ्न नहुने सीमा (runtime मा लागू हुने)। सँगै मिलेर तिनले Pod कहाँ राखिने, दबाबमा कसरी 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
Request र limit नै Kubernetes ले सीमित node स्रोतहरूलाई निष्पक्ष र पूर्वानुमानयोग्य रूपमा बाँड्ने तरिका हुन्, त्यसैले यो भिन्नता र यसका परिणाम बुझ्नु अत्यावश्यक performance र reliability ज्ञान हो। मुख्य अन्तर्दृष्टि हो कि तिनले फरक-फरक उद्देश्य पूरा गर्छन्: request एउटा ग्यारेन्टी गरिएको आरक्षण हो जुन scheduler ले Pod राख्न प्रयोग गर्छ (node मा ठाउँ छ कि भनी request हरू जोडेर, limit बेवास्ता गर्दै), भने limit एउटा runtime सीमा हो जुन प्रत्येक स्रोतका लागि फरक तरिकाले लागू हुन्छ — CPU limit नाघ्दा तपाईं throttled (सुस्त) हुनुहुन्छ, तर memory limit नाघ्दा container OOM-kill भई restart हुन्छ। request गलत पार्नुको दुवैतर्फ वास्तविक मूल्य छ: धेरै कम पार्दा node overcommit हुन्छन् र Pod हरू एक-अर्कालाई भोकाउँछन्; धेरै बढी पार्दा capacity खेर जान्छ र केही नअटाएर Pod हरू Pending मा बस्छन्। तीन QoS class — Guaranteed (request बराबर limit), Burstable (request limit भन्दा कम), र BestEffort (केही सेट नगरिएको) — memory दबाबमा eviction क्रम निर्धारण गर्छन्, BestEffort पहिले र Guaranteed अन्तिममा मारिने गरी, जुन ठ्याक्कै तपाईंले महत्त्वपूर्ण workload जोगाउन बुझ्नुपर्ने कुरा हो। व्यावहारिक मार्गदर्शन थाहा पाउनु (महत्त्वपूर्ण एपका लागि memory request बराबर limit सेट गर्ने, kubectl top मार्फत वास्तविक उपयोगबाट right-size गर्ने, LimitRange/ResourceQuota ले default लागू गर्ने) ले यसलाई सिद्धान्तबाट सुदृढ capacity planning मा बदल्छ। किनभने स्रोतको गलत configuration वास्तविक cluster मा अस्थिरता, खेर गएको खर्च, र Pending Pod को सबैभन्दा सामान्य कारणमध्ये एक हो, request, limit र QoS मा दक्षता कुशल र स्थिर Kubernetes workload चलाउने आधारभूत कुरा हो।
विस्तृत उत्तरसहित IT अन्तर्वार्ता प्रश्नहरूको पुस्तकालय — जुनियरदेखि सिनियरसम्म।
दान गर्नुहोस्