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)** class મળે.

## Requests vs 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 classes (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>               # Allocated resources vs capacity
```

## વ્યાવહારિક માર્ગદર્શન

```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 resources ને ન્યાયી અને અનુમાનક્ષમ રીતે વહેંચે છે, તેથી આ ભેદ અને તેના પરિણામો સમજવા આવશ્યક performance અને reliability જ્ઞાન છે. મુખ્ય સૂઝ એ છે કે તે અલગ હેતુઓ સાધે છે: **requests** એ ખાતરીપૂર્વકનું reservation છે જેનો ઉપયોગ **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 (કંઈ set નથી) — memory દબાણ હેઠળ eviction ક્રમ નક્કી કરે છે, જેમાં BestEffort પહેલું kill થાય અને Guaranteed છેલ્લું, જે critical workloads ને સુરક્ષિત કરવા સમજવું જરૂરી છે. વ્યાવહારિક માર્ગદર્શન જાણવું (critical apps માટે memory requests limits બરાબર set કરો, `kubectl top` દ્વારા વાસ્તવિક ઉપયોગથી right-size કરો, LimitRange/ResourceQuota થી defaults લાગુ કરો) આને સિદ્ધાંતમાંથી સાચા capacity planning માં ફેરવે છે. કારણ કે resource misconfiguration એ વાસ્તવિક clusters માં અસ્થિરતા, વેડફાયેલા ખર્ચ, અને Pending Pods નાં સૌથી સામાન્ય કારણોમાંનું એક છે, requests, limits, અને QoS પર પ્રભુત્વ મેળવવું એ કાર્યક્ષમ, સ્થિર Kubernetes workloads ચલાવવા માટે પાયાનું છે.

Requests vs limits

Scheduling requests નો ઉપયોગ કેવી રીતે કરે છે

QoS classes (memory દબાણ હેઠળ eviction ક્રમ નક્કી કરે)

વ્યાવહારિક માર્ગદર્શન

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો