ما الفرق بين requests وlimits الخاصة بالـ CPU/الذاكرة، وكيف تؤثّر على الجدولة (scheduling) والإخلاء (eviction) وفئة QoS؟

Question

IT Interview Practice · Accepted Answer

الـ **requests** هي ما تُضمَن للحاوية (وتُستخدم في الجدولة)؛ والـ **limits** هي *السقف* الذي لا يجوز تجاوزه (يُفرَض في وقت التشغيل). معاً تحدّدان أين تُوضَع الـ Pods، وكيف تُخنَق (throttled) أو تُقتَل تحت الضغط، وأيّ فئة **جودة خدمة (QoS)** يحصل عليها الـ Pod.

## 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"        # 0.25 من نواة، مضمونة
          memory: "256Mi"
        limits:
          cpu: "500m"        # قد ترتفع إلى 0.5 نواة ثم تُخنَق
          memory: "512Mi"    # تجاوز هذا → OOMKilled
```

## كيف تستخدم الجدولة الـ 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 (تحدّد ترتيب الإخلاء تحت ضغط الذاكرة)

```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/الذاكرة
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 لموارد العقدة المحدودة بعدلٍ وقابلية تنبّؤ، لذا فإن فهم الفرق ونتائجه معرفةٌ ضرورية للأداء والموثوقية. الاستنتاج الجوهري أنهما يخدمان غرضين مختلفين: فالـ **requests** حجز مضمون يستخدمه الـ **scheduler** لوضع الـ Pods (يجمع الـ requests ليقرّر ما إذا كانت العقدة تتّسع، متجاهلاً الـ limits)، بينما الـ **limits** سقف يُفرَض في وقت التشغيل بشكل مختلف لكل مورد — فتجاوز حدّ الـ **CPU** يجعلك تُخنَق (تُبطَّأ)، لكن تجاوز حدّ الـ **الذاكرة** يجعل الحاوية تُقتَل بسبب نفاد الذاكرة (OOM-killed) ثم تُعاد تشغيلها. إن الخطأ في الـ requests له تكاليف حقيقية على الجانبين: أدنى من اللازم فتصبح العقد مثقلة بالالتزامات فتتضوّر الـ Pods جوعاً؛ وأعلى من اللازم فتُهدَر السعة بينما تبقى الـ Pods في حالة Pending لأن لا شيء يتّسع. تحدّد فئات **QoS** الثلاث — Guaranteed (requests تساوي limits) وBurstable (requests أدنى من limits) وBestEffort (لا شيء محدّد) — ترتيب الإخلاء تحت ضغط الذاكرة، حيث تُقتَل BestEffort أولاً وGuaranteed أخيراً، وهو بالضبط ما تحتاج فهمه لحماية الـ workloads الحرجة. إن معرفة الإرشادات العملية (اجعل requests الذاكرة تساوي limits للتطبيقات الحرجة، اضبط الحجم الصحيح من الاستخدام الفعلي عبر `kubectl top`، افرض الافتراضات بـ LimitRange/ResourceQuota) تحوّل هذا من نظرية إلى تخطيط سعة سليم. ولأن سوء إعداد الموارد من أكثر أسباب عدم الاستقرار وهدر الإنفاق والـ Pods العالقة في Pending شيوعاً في العناقيد الحقيقية، فإن إتقان الـ requests والـ limits وQoS أساسٌ لتشغيل workloads فعّالة ومستقرّة على Kubernetes.

requests مقابل limits

كيف تستخدم الجدولة الـ requests

فئات QoS (تحدّد ترتيب الإخلاء تحت ضغط الذاكرة)

إرشادات عملية

لماذا يهم

أسئلة ذات صلة