CPU/memory requests اور limits میں کیا فرق ہے، اور یہ scheduling، eviction، اور QoS کو کیسے متاثر کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**Requests** وہ ہیں جن کی ایک container کو *ضمانت* دی جاتی ہے (scheduling کے لیے استعمال ہوتے ہیں)؛ **limits** وہ *چھت* ہیں جسے وہ عبور نہیں کر سکتا (runtime پر نافذ)۔ مل کر یہ طے کرتے ہیں کہ Pods کہاں رکھے جائیں، دباؤ کے تحت انہیں کیسے throttle یا kill کیا جائے، اور ایک Pod کو کون سا **Quality of Service (QoS)** طبقہ ملے۔

## Requests بمقابلہ limits

```text
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)
```

```yaml
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
```

## scheduling کیسے requests استعمال کرتا ہے

```text
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).
```

## QoS طبقات (memory دباؤ کے تحت eviction کی ترتیب طے کرتے ہیں)

```text
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
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # اصل CPU/memory استعمال
kubectl describe node <node>               # مختص وسائل بمقابلہ گنجائش
```

## عملی رہنمائی

```text
✓ 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 وسائل کو منصفانہ اور قابلِ پیش گوئی انداز میں بانٹتا ہے، اس لیے فرق کو اور اس کے نتائج کو سمجھنا ایک ضروری performance اور reliability کا علم ہے۔ مرکزی بصیرت یہ ہے کہ یہ مختلف مقاصد پورے کرتے ہیں: **requests** ایک ضمانت شدہ ریزرویشن ہیں جسے **scheduler** Pods رکھنے کے لیے استعمال کرتا ہے (requests کو جمع کر کے یہ فیصلہ کرتا ہے کہ node میں جگہ ہے یا نہیں، limits کو نظر انداز کرتے ہوئے)، جبکہ **limits** ایک runtime چھت ہیں جو فی وسیلہ مختلف طریقے سے نافذ ہوتی ہیں — ایک **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 کی حفاظت کے لیے سمجھنا چاہیے۔ عملی رہنمائی کو جاننا (تنقیدی ایپس کے لیے memory requests کو limits کے برابر رکھیں، `kubectl top` کے ذریعے حقیقی استعمال سے right-size کریں، LimitRange/ResourceQuota کے ساتھ defaults نافذ کریں) اسے نظریے سے درست capacity planning میں بدل دیتا ہے۔ چونکہ وسائل کی غلط کنفیگریشن حقیقی clusters میں عدم استحکام، ضائع ہونے والے خرچ، اور Pending Pods کی سب سے عام وجوہات میں سے ایک ہے، requests، limits، اور QoS پر عبور Kubernetes workloads کو مؤثر اور مستحکم انداز میں چلانے کے لیے بنیادی ہے۔

Requests بمقابلہ limits

scheduling کیسے requests استعمال کرتا ہے

QoS طبقات (memory دباؤ کے تحت eviction کی ترتیب طے کرتے ہیں)

عملی رہنمائی

یہ کیوں اہم ہے

متعلقہ سوالات