Care este diferența dintre CPU/memory requests și limits și cum afectează ele scheduling-ul, eviction-ul și QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** sunt ceea ce i se *garantează* unui container (folosite pentru scheduling); **limits** sunt *plafonul* pe care nu îl poate depăși (impus la runtime). Împreună determină unde sunt plasate Pod-urile, cum sunt încetinite (throttled) sau ucise sub presiune și ce clasă de **Quality of Service (QoS)** primește un Pod.

## Requests vs limits

```text
REQUEST → cantitatea REZERVATĂ pentru container. SCHEDULER-ul folosește suma
          request-urilor pentru a decide dacă un node are loc. Acesta e nivelul tău garantat.
LIMIT   → MAXIMUL pe care containerul îl poate folosi. Impus la runtime:
          CPU peste limită    → THROTTLED (încetinit, nu ucis)
          memorie peste limită → OOM-KILLED (containerul terminat, apoi repornit)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 dintr-un core, garantat
          memory: "256Mi"
        limits:
          cpu: "500m"        # poate crește (burst) la 0.5 core, apoi throttled
          memory: "512Mi"    # depășește asta → OOMKilled
```

## Cum folosește scheduling-ul request-urile

```text
Node-ul are 4 CPU / 8Gi alocabile.
Scheduler-ul însumează REQUEST-urile Pod-urilor deja plasate; un Pod nou încape doar dacă
request-urile sale mai încap în ce a rămas. (Limits NU sunt folosite pentru plasare.)
→ Setezi request-uri prea mici → node suprasolicitat, Pod-urile se luptă pe resurse.
→ Setezi request-uri prea mari → capacitate irosită, Pod-uri blocate în Pending (nimic nu încape).
```

## Clasele QoS (decid ordinea de eviction sub presiune de memorie)

```text
Guaranteed  → requests == limits pentru AMBELE cpu & memorie (fiecare container)
              → ultimul care e evacuat (prioritate maximă)
Burstable   → are requests dar sunt < limits (sau setate parțial)
              → evacuat după BestEffort
BestEffort  → deloc requests sau limits
              → PRIMUL evacuat când node-ul rămâne fără memorie
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # utilizarea reală de CPU/memorie
kubectl describe node <node>               # resurse alocate vs capacitate
```

## Îndrumar practic

```text
✓ Setează mereu memory requests = limits pentru comportament predictibil, OOM-safe pe aplicații critice
✓ Setează CPU requests la nevoia de regim stabil; CPU limits sunt adesea lăsate deoparte pentru a permite burst
✓ Dimensionează corect din utilizarea reală (kubectl top / metrics) — nu din presupuneri
✓ Folosește LimitRange / ResourceQuota pentru a impune valori implicite rezonabile per namespace
```

## De ce contează

Requests și limits sunt modul în care Kubernetes împarte resursele finite ale node-urilor corect și predictibil, așa că înțelegerea distincției și a consecințelor ei este cunoaștere esențială de performanță și fiabilitate. Intuiția centrală este că servesc scopuri diferite: **requests** sunt o rezervare garantată pe care **scheduler-ul** o folosește pentru a plasa Pod-uri (însumând request-urile pentru a decide dacă un node are loc, ignorând limits), în timp ce **limits** sunt un plafon la runtime impus diferit per resursă — depășirea unei limite de **CPU** te aduce în **throttling** (încetinit), dar depășirea unei limite de **memorie** face containerul **OOM-killed** și repornit. Setarea greșită a request-urilor are costuri reale de ambele părți: prea mici și node-urile devin suprasolicitate, deci Pod-urile se înfometează reciproc; prea mari și capacitatea e irosită în timp ce Pod-urile stau în Pending pentru că nimic nu încape. Cele trei **clase QoS** — Guaranteed (requests egale cu limits), Burstable (requests sub limits) și BestEffort (nimic setat) — determină ordinea de eviction sub presiune de memorie, cu BestEffort ucis primul și Guaranteed ultimul, exact ce trebuie să înțelegi pentru a proteja workload-urile critice. Cunoașterea îndrumarului practic (setează memory requests egale cu limits pentru aplicațiile critice, dimensionează din utilizarea reală via `kubectl top`, impune valori implicite cu LimitRange/ResourceQuota) transformă asta din teorie în planificare solidă de capacitate. Deoarece configurarea greșită a resurselor este una dintre cele mai comune cauze de instabilitate, cheltuială irosită și Pod-uri în Pending în clusterele reale, stăpânirea request-urilor, limits și QoS este fundamentală pentru a rula workload-uri Kubernetes eficiente și stabile.

Requests vs limits

Cum folosește scheduling-ul request-urile

Clasele QoS (decid ordinea de eviction sub presiune de memorie)

Îndrumar practic

De ce contează

Întrebări conexe