CPU/memory requests మరియు limits మధ్య తేడా ఏమిటి, అవి scheduling, eviction, మరియు QoSను ఎలా ప్రభావితం చేస్తాయి?

Question

IT Interview Practice · Accepted Answer

**Requests** అనేవి ఒక containerకు *guarantee* చేయబడినవి (scheduling కోసం వాడతారు); **limits** అనేవి అది దాటకూడని *గరిష్ఠ పరిమితి* (runtimeలో అమలు). కలిసి అవి Pods ఎక్కడ ఉంచబడతాయో, ఒత్తిడిలో అవి ఎలా throttle లేదా kill చేయబడతాయో, మరియు ఒక Pod ఏ **Quality of Service (QoS)** class పొందుతుందో నిర్ణయిస్తాయి.

## Requests vs limits

```text
REQUEST → containerకు RESERVE చేయబడిన మొత్తం. SCHEDULER requests మొత్తాన్ని వాడి ఒక nodeకు
          చోటు ఉందా అని నిర్ణయిస్తుంది. ఇది మీ guaranteed కనీస స్థాయి (floor).
LIMIT   → container వాడగల గరిష్ఠం (MAX). runtimeలో అమలు:
          CPU limit దాటితే    → THROTTLE (నెమ్మది చేయబడుతుంది, kill కాదు)
          memory limit దాటితే → OOM-KILL (container terminate, తర్వాత restart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 core, guaranteed
          memory: "256Mi"
        limits:
          cpu: "500m"        # 0.5 core వరకు burst కావచ్చు, తర్వాత throttle
          memory: "512Mi"    # దీన్ని దాటితే → OOMKilled
```

## scheduling requestsను ఎలా వాడుతుంది

```text
nodeకు 4 CPU / 8Gi allocatable ఉంది.
Scheduler ఇప్పటికే ఉంచిన Pods యొక్క REQUESTS కూడతుంది; ఒక కొత్త Pod దాని requests
మిగిలిన దానిలో ఇంకా సరిపోతేనే సరిపోతుంది. (Limits placement కోసం వాడరు.)
→ requests చాలా తక్కువ పెడితే → node overcommit, Pods resources కోసం పోరాడతాయి.
→ requests చాలా ఎక్కువ పెడితే → వృథా capacity, Pods Pendingలో ఇరుక్కుంటాయి (ఏదీ సరిపోదు).
```

## QoS classes (memory ఒత్తిడిలో eviction క్రమం నిర్ణయిస్తాయి)

```text
Guaranteed  → cpu & memory రెండింటికీ requests == limits (ప్రతి container)
              → చివరగా evict (అత్యధిక ప్రాధాన్యత)
Burstable   → requests ఉన్నాయి కానీ limits కంటే తక్కువ (లేదా పాక్షికంగా set)
              → BestEffort తర్వాత evict
BestEffort  → requests లేదా limits అస్సలు లేవు
              → node memory తక్కువైనప్పుడు మొదట evict
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # అసలు CPU/memory వినియోగం
kubectl describe node <node>               # కేటాయించిన resources vs capacity
```

## ఆచరణాత్మక మార్గదర్శకం

```text
✓ critical apps‌లో predictable, OOM-safe ప్రవర్తన కోసం ఎప్పుడూ memory requests = limits పెట్టు
✓ CPU requestsను steady-state అవసరానికి పెట్టు; bursting కోసం CPU limits తరచుగా వదిలేస్తారు
✓ నిజ వినియోగం నుండి right-size చేయి (kubectl top / metrics) — ఊహలతో కాదు
✓ namespaceకి సరైన defaults అమలు చేయడానికి LimitRange / ResourceQuota వాడు
```

## ఇది ఎందుకు ముఖ్యం

Requests మరియు limits అనేవి Kubernetes పరిమిత node resourcesను న్యాయంగా మరియు predictableగా ఎలా పంచుకుంటుందో, కాబట్టి తేడాను మరియు దాని పర్యవసానాలను అర్థం చేసుకోవడం అత్యవసరమైన performance మరియు reliability జ్ఞానం. ప్రధాన అంతర్దృష్టి అవి వేర్వేరు ప్రయోజనాలకు ఉపయోగపడతాయని: **requests** అనేది **scheduler** Pods ఉంచడానికి వాడే ఒక guaranteed reservation (ఒక nodeకు చోటు ఉందా అని నిర్ణయించడానికి requests కూడతుంది, limits విస్మరిస్తుంది), while **limits** అనేది resourceను బట్టి భిన్నంగా అమలు చేయబడే ఒక runtime ceiling — ఒక **CPU** limit దాటడం మిమ్మల్ని **throttle** (నెమ్మది) చేస్తుంది, కానీ ఒక **memory** limit దాటడం containerను **OOM-kill** చేసి restart చేస్తుంది. requests తప్పుగా పెట్టడం రెండు వైపులా నిజ ఖర్చులు కలిగి ఉంటుంది: చాలా తక్కువ అయితే nodes overcommit అయి 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కి సమానంగా పెట్టడం, `kubectl top` ద్వారా నిజ వినియోగం నుండి right-size చేయడం, LimitRange/ResourceQuotaతో defaults అమలు చేయడం) దీన్ని theory నుండి మంచి capacity planningగా మారుస్తుంది. resource misconfiguration నిజ clustersలో అస్థిరత, వృథా ఖర్చు, మరియు Pending Podsకు అత్యంత సాధారణ కారణాల్లో ఒకటి కాబట్టి, requests, limits, మరియు QoS ప్రావీణ్యం సమర్థవంతమైన, స్థిరమైన Kubernetes workloads నడపడానికి పునాది.

Requests vs limits

scheduling requestsను ఎలా వాడుతుంది

QoS classes (memory ఒత్తిడిలో eviction క్రమం నిర్ణయిస్తాయి)

ఆచరణాత్మక మార్గదర్శకం

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు