Hvad er forskellen mellem CPU/memory requests og limits, og hvordan påvirker de scheduling, eviction og QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** er, hvad en container er *garanteret* (bruges til scheduling); **limits** er *loftet*, den ikke må overskride (håndhæves ved runtime). Sammen styrer de, hvor Pods placeres, hvordan de throttles eller dræbes under pres, og hvilken **Quality of Service (QoS)**-klasse en Pod får.

## Requests vs limits

```text
REQUEST → mængden RESERVERET til containeren. SCHEDULEREN bruger summen af
          requests til at afgøre, om en node har plads. Dette er dit garanterede gulv.
LIMIT   → MAKS, containeren må bruge. Håndhæves ved runtime:
          CPU over limit    → THROTTLED (bremset, ikke dræbt)
          memory over limit → OOM-KILLED (container termineret, derefter genstartet)
```

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

## Hvordan scheduling bruger requests

```text
Node har 4 CPU / 8Gi allokerbar.
Scheduleren summerer REQUESTS for allerede placerede Pods; en ny Pod passer kun, hvis dens
requests stadig kan være i det, der er tilbage. (Limits bruges IKKE til placering.)
→ Sæt requests for lavt → node overcommitted, Pods slås om ressourcer.
→ Sæt requests for højt → spildt kapacitet, Pods hænger i Pending (intet passer).
```

## QoS-klasser (afgør eviction-rækkefølge under memory-pres)

```text
Guaranteed  → requests == limits for BÅDE cpu & memory (hver container)
              → sidst til at blive evicted (højeste prioritet)
Burstable   → har requests, men de er < limits (eller delvist sat)
              → evicted efter BestEffort
BestEffort  → slet ingen requests eller limits
              → FØRST til at blive evicted, når noden løber lav på memory
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # faktisk CPU/memory-forbrug
kubectl describe node <node>               # Allokerede ressourcer vs kapacitet
```

## Praktisk vejledning

```text
✓ Sæt altid memory requests = limits for forudsigelig, OOM-sikker adfærd på kritiske apps
✓ Sæt CPU requests til det stabile behov; CPU limits udelades ofte for at tillade bursting
✓ Dimensionér ud fra reelt forbrug (kubectl top / metrics) — ikke gæt
✓ Brug LimitRange / ResourceQuota til at håndhæve fornuftige defaults pr. namespace
```

## Hvorfor det betyder noget

Requests og limits er måden, Kubernetes deler endelige node-ressourcer retfærdigt og forudsigeligt på, så det er essentiel viden om performance og pålidelighed at forstå skelnen og dens konsekvenser. Kerneindsigten er, at de tjener forskellige formål: **requests** er en garanteret reservation, som **scheduleren** bruger til at placere Pods (summerer requests for at afgøre, om en node har plads, og ignorerer limits), mens **limits** er et runtime-loft, der håndhæves forskelligt pr. ressource — at overskride en **CPU**-limit får dig **throttled** (bremset), men at overskride en **memory**-limit får containeren **OOM-killed** og genstartet. At sætte requests forkert har reelle omkostninger på begge sider: for lavt, og nodes bliver overcommitted, så Pods udsulter hinanden; for højt, og kapacitet spildes, mens Pods hænger i Pending, fordi intet passer. De tre **QoS-klasser** — Guaranteed (requests lig limits), Burstable (requests under limits) og BestEffort (intet sat) — afgør eviction-rækkefølgen under memory-pres, hvor BestEffort dræbes først og Guaranteed sidst, hvilket er præcis, hvad du skal forstå for at beskytte kritiske workloads. At kende den praktiske vejledning (sæt memory requests lig limits for kritiske apps, dimensionér ud fra reelt forbrug via `kubectl top`, håndhæv defaults med LimitRange/ResourceQuota) forvandler dette fra teori til sund kapacitetsplanlægning. Fordi fejlkonfiguration af ressourcer er en af de mest almindelige årsager til ustabilitet, spildt forbrug og Pending Pods i rigtige klynger, er det at mestre requests, limits og QoS fundamentalt for at køre effektive, stabile Kubernetes-workloads.

Requests vs limits

Hvordan scheduling bruger requests

QoS-klasser (afgør eviction-rækkefølge under memory-pres)

Praktisk vejledning

Hvorfor det betyder noget

Relaterede spørgsmål