Qual è la differenza tra request e limit di CPU/memoria, e come influenzano scheduling, eviction e QoS?

Question

IT Interview Practice · Accepted Answer

Le **request** sono ciò che a un container è *garantito* (usate per lo scheduling); i **limit** sono il *tetto* che non può superare (imposto a runtime). Insieme determinano dove vengono collocati i Pod, come vengono limitati o uccisi sotto pressione, e quale classe di **Quality of Service (QoS)** ottiene un Pod.

## Request vs limit

```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 of a core, guaranteed
          memory: "256Mi"
        limits:
          cpu: "500m"        # may burst to 0.5 core, then throttled
          memory: "512Mi"    # exceed this → OOMKilled
```

## Come lo scheduling usa le request

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

## Classi QoS (decidono l'ordine di eviction sotto pressione di memoria)

```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                           # actual CPU/memory usage
kubectl describe node <node>               # Allocated resources vs capacity
```

## Indicazioni pratiche

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

## Perché è importante

Request e limit sono il modo in cui Kubernetes condivide le risorse finite dei node in modo equo e prevedibile, quindi capire la distinzione e le sue conseguenze è una conoscenza essenziale in materia di prestazioni e affidabilità. L'intuizione centrale è che servono a scopi diversi: le **request** sono una prenotazione garantita che lo **scheduler** usa per collocare i Pod (sommando le request per decidere se un node ha spazio, ignorando i limit), mentre i **limit** sono un tetto a runtime imposto in modo diverso per ciascuna risorsa — superare un limite di **CPU** ti fa **throttlare** (rallentare), ma superare un limite di **memoria** fa **OOM-killare** e riavviare il container. Sbagliare le request ha costi reali su entrambi i fronti: troppo basse e i node vanno in overcommit così i Pod si affamano a vicenda; troppo alte e la capacità viene sprecata mentre i Pod restano in Pending perché nulla ci sta. Le tre **classi QoS** — Guaranteed (request uguali ai limit), Burstable (request sotto i limit) e BestEffort (nulla impostato) — determinano l'ordine di eviction sotto pressione di memoria, con BestEffort ucciso per primo e Guaranteed per ultimo, che è esattamente ciò che devi capire per proteggere i workload critici. Conoscere le indicazioni pratiche (impostare le request di memoria uguali ai limit per le app critiche, dimensionare correttamente in base all'uso reale via `kubectl top`, imporre default con LimitRange/ResourceQuota) trasforma questo da teoria in un solido capacity planning. Poiché la cattiva configurazione delle risorse è una delle cause più comuni di instabilità, spesa sprecata e Pod in Pending nei cluster reali, padroneggiare request, limit e QoS è fondamentale per far girare workload Kubernetes efficienti e stabili.

Request vs limit

Come lo scheduling usa le request

Classi QoS (decidono l'ordine di eviction sotto pressione di memoria)

Indicazioni pratiche

Perché è importante

Domande correlate