Hva er forskjellen mellom CPU/minne-requests og limits, og hvordan påvirker de scheduling, eviction og QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** er hva en container er *garantert* (brukt til scheduling); **limits** er *taket* den ikke får overskride (håndhevet ved runtime). Sammen bestemmer de hvor Pods plasseres, hvordan de throttles eller drepes under press, og hvilken **Quality of Service (QoS)**-klasse en Pod får.

## Requests vs limits

```text
REQUEST → mengden RESERVERT for containeren. SCHEDULEREN bruker summen av
          requests for å avgjøre om en node har plass. Dette er ditt garanterte gulv.
LIMIT   → MAKS containeren kan bruke. Håndhevet ved runtime:
          CPU over limit    → THROTTLED (bremset, ikke drept)
          minne over limit  → OOM-KILLED (container terminert, så restartet)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0,25 av en kjerne, garantert
          memory: "256Mi"
        limits:
          cpu: "500m"        # kan burste til 0,5 kjerne, så throttled
          memory: "512Mi"    # overskrid dette → OOMKilled
```

## Hvordan scheduling bruker requests

```text
Noden har 4 CPU / 8Gi allokerbart.
Scheduleren summerer REQUESTS til Pods allerede plassert; en ny Pod passer bare hvis
requestene fortsatt får plass i det som gjenstår. (Limits brukes IKKE til plassering.)
→ Sett requests for lavt → node overcommitted, Pods slåss om ressurser.
→ Sett requests for høyt → bortkastet kapasitet, Pods sitter fast i Pending (ingenting passer).
```

## QoS-klasser (avgjør eviction-rekkefølge under minnepress)

```text
Guaranteed  → requests == limits for BÅDE cpu og minne (hver container)
              → sist til å bli evicted (høyest prioritet)
Burstable   → har requests, men de er < limits (eller delvis satt)
              → evicted etter BestEffort
BestEffort  → ingen requests eller limits i det hele tatt
              → FØRST til å bli evicted når noden går tom for minne
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # faktisk CPU/minne-bruk
kubectl describe node <node>               # Allokerte ressurser vs kapasitet
```

## Praktiske råd

```text
✓ Sett alltid minne-requests = limits for forutsigbar, OOM-trygg atferd på kritiske apper
✓ Sett CPU-requests til steady-state-behovet; CPU-limits utelates ofte for å tillate bursting
✓ Riktig-dimensjoner fra reell bruk (kubectl top / metrics) — ikke gjetting
✓ Bruk LimitRange / ResourceQuota for å håndheve fornuftige defaults per namespace
```

## Hvorfor det er viktig

Requests og limits er hvordan Kubernetes deler endelige node-ressurser rettferdig og forutsigbart, så å forstå skillet og konsekvensene er essensiell ytelses- og pålitelighetskunnskap. Kjerneinnsikten er at de tjener ulike formål: **requests** er en garantert reservasjon som **scheduleren** bruker til å plassere Pods (summerer requests for å avgjøre om en node har plass, ignorerer limits), mens **limits** er et runtime-tak håndhevet ulikt per ressurs — å overskride en **CPU**-limit gir deg **throttling** (bremset), men å overskride en **minne**-limit får containeren **OOM-drept** og restartet. Å få requests feil har reelle kostnader på begge sider: for lavt og noder blir overcommitted slik at Pods sulter hverandre; for høyt og kapasitet sløses mens Pods sitter i Pending fordi ingenting passer. De tre **QoS-klassene** — Guaranteed (requests lik limits), Burstable (requests under limits) og BestEffort (ingenting satt) — bestemmer eviction-rekkefølgen under minnepress, med BestEffort drept først og Guaranteed sist, som er nettopp hva du må forstå for å beskytte kritiske workloads. Å kjenne de praktiske rådene (sett minne-requests lik limits for kritiske apper, riktig-dimensjoner fra reell bruk via `kubectl top`, håndhev defaults med LimitRange/ResourceQuota) gjør dette fra teori til god kapasitetsplanlegging. Fordi feilkonfigurering av ressurser er en av de vanligste årsakene til ustabilitet, bortkastet forbruk og Pending Pods i ekte klynger, er det å mestre requests, limits og QoS grunnleggende for å kjøre effektive, stabile Kubernetes-workloads.

Requests vs limits

Hvordan scheduling bruker requests

QoS-klasser (avgjør eviction-rekkefølge under minnepress)

Praktiske råd

Hvorfor det er viktig

Relaterte spørsmål