Koja je razlika između CPU/memory requestova i limita te kako utječu na scheduling, izbacivanje (eviction) i QoS?

Question

IT Interview Practice · Accepted Answer

**Requestovi** su ono što je kontejneru *zajamčeno* (koristi se za scheduling); **limiti** su *gornja granica* koju ne smije prijeći (nameće se u vrijeme izvođenja). Zajedno određuju gdje se Podovi smještaju, kako se usporavaju ili ubijaju pod pritiskom te koju **Quality of Service (QoS)** klasu Pod dobiva.

## Requestovi naspram limita

```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 jezgre, zajamčeno
          memory: "256Mi"
        limits:
          cpu: "500m"        # može skočiti do 0.5 jezgre, zatim throttling
          memory: "512Mi"    # prijeđe li ovo → OOMKilled
```

## Kako scheduling koristi requestove

```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 klase (određuju redoslijed izbacivanja pod pritiskom na memoriju)

```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                           # stvarno korištenje CPU-a/memorije
kubectl describe node <node>               # dodijeljeni resursi naspram kapaciteta
```

## Praktične smjernice

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

## Zašto je to važno

Requestovi i limiti su način na koji Kubernetes pravedno i predvidljivo dijeli ograničene resurse nodea, pa je razumijevanje te razlike i njezinih posljedica bitno znanje o performansama i pouzdanosti. Jezgreni uvid je da služe različitim svrhama: **requestovi** su zajamčena rezervacija koju **scheduler** koristi za smještanje Podova (zbraja requestove kako bi odlučio ima li node mjesta, ignorirajući limite), dok su **limiti** gornja granica u vrijeme izvođenja koja se drugačije nameće po resursu — prekoračenje **CPU** limita donosi **throttling** (usporavanje), ali prekoračenje **memory** limita donosi **OOM-kill** kontejnera i restart. Pogrešni requestovi imaju stvarne troškove na obje strane: premali i nodeovi postaju preopterećeni pa Podovi gladuju jedan drugoga; preveliki i kapacitet se troši dok Podovi stoje u Pending stanju jer ništa ne stane. Tri **QoS klase** — Guaranteed (requestovi jednaki limitima), Burstable (requestovi ispod limita) i BestEffort (ništa postavljeno) — određuju redoslijed izbacivanja pod pritiskom na memoriju, pri čemu se BestEffort ubija prvi, a Guaranteed zadnji, što je upravo ono što trebate razumjeti za zaštitu kritičnih workloadova. Poznavanje praktičnih smjernica (postavite memory requestove jednake limitima za kritične aplikacije, dimenzionirajte prema stvarnom korištenju preko `kubectl top`, nametnite zadane vrijednosti kroz LimitRange/ResourceQuota) pretvara ovo iz teorije u razumno planiranje kapaciteta. Budući da je pogrešna konfiguracija resursa jedan od najčešćih uzroka nestabilnosti, potrošenog novca i Pending Podova u stvarnim klasterima, ovladavanje requestovima, limitima i QoS-om temeljno je za pokretanje učinkovitih, stabilnih Kubernetes workloadova.

Requestovi naspram limita

Kako scheduling koristi requestove

QoS klase (određuju redoslijed izbacivanja pod pritiskom na memoriju)

Praktične smjernice

Zašto je to važno

Povezana pitanja