Kakšna je razlika med CPU/pomnilniškimi requests in limits ter kako vplivajo na razporejanje (scheduling), izселjevanje (eviction) in QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** so tisto, kar je vsebniku *zagotovljeno* (uporablja se za razporejanje); **limits** so *zgornja meja*, ki je ne sme preseči (uveljavljena med izvajanjem). Skupaj določajo, kam se Podi umestijo, kako se pod pritiskom dušijo ali ubijejo, in kateri razred **Quality of Service (QoS)** Pod dobi.

## Requests proti 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"        # 0,25 jedra, zagotovljeno
          memory: "256Mi"
        limits:
          cpu: "500m"        # lahko naraste na 0,5 jedra, nato se duši
          memory: "512Mi"    # preseganje tega → OOMKilled
```

## Kako razporejanje uporablja 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).
```

## Razredi QoS (določajo vrstni red izseljevanja pod pomnilniškim pritiskom)

```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                           # dejanska poraba CPU/pomnilnika
kubectl describe node <node>               # dodeljeni viri proti zmogljivosti
```

## Praktične smernice

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

## Zakaj je to pomembno

Requests in limits so način, kako Kubernetes pošteno in predvidljivo deli končne vire nodov, zato je razumevanje razlike in njenih posledic bistveno znanje o zmogljivosti in zanesljivosti. Jedrni uvid je, da služijo različnim namenom: **requests** so zagotovljena rezervacija, ki jo **scheduler** uporablja za umeščanje Podov (sešteje requests, da ugotovi, ali ima node prostor, in ne upošteva limits), medtem ko so **limits** zgornja meja med izvajanjem, ki se za vsak vir uveljavlja drugače — preseganje **CPU** limita vas **duši (throttle)** (upočasni), preseganje **pomnilniškega** limita pa povzroči, da se vsebnik **ubije zaradi OOM (OOM-kill)** in znova zažene. Napačno nastavljeni requests imajo resnične stroške na obeh straneh: prenizki in nodi postanejo prezasedeni (overcommitted), tako da si Podi kradejo vire; previsoki in zmogljivost je zapravljena, medtem ko Podi obtičijo v Pending, ker nič ne ustreza. Trije **razredi QoS** — Guaranteed (requests enaki limits), Burstable (requests pod limits) in BestEffort (nič nastavljeno) — določajo vrstni red izseljevanja pod pomnilniškim pritiskom, pri čemer se BestEffort ubije prvi in Guaranteed zadnji, kar je natanko tisto, kar morate razumeti za zaščito kritičnih delovnih obremenitev. Poznavanje praktičnih smernic (za kritične aplikacije nastavite pomnilniške requests enako limits, pravilno določite velikost iz dejanske porabe prek `kubectl top`, uveljavite privzete vrednosti z LimitRange/ResourceQuota) to spremeni iz teorije v trdno načrtovanje zmogljivosti. Ker je napačna konfiguracija virov eden najpogostejših vzrokov nestabilnosti, zapravljene porabe in Podov v Pending v resničnih gručah, je obvladovanje requests, limits in QoS temeljno za poganjanje učinkovitih in stabilnih delovnih obremenitev Kubernetes.

Requests proti limits

Kako razporejanje uporablja requests

Razredi QoS (določajo vrstni red izseljevanja pod pomnilniškim pritiskom)

Praktične smernice

Zakaj je to pomembno

Povezana vprašanja