Wat is het verschil tussen CPU/geheugen-requests en -limits, en hoe beïnvloeden ze scheduling, eviction en QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** zijn wat een container *gegarandeerd* krijgt (gebruikt voor scheduling); **limits** zijn het *plafond* dat hij niet mag overschrijden (afgedwongen at runtime). Samen bepalen ze waar Pods geplaatst worden, hoe ze onder druk worden gethrottled of gedood, en welke **Quality of Service (QoS)**-klasse een Pod krijgt.

## Requests vs limits

```text
REQUEST → de hoeveelheid GERESERVEERD voor de container. De SCHEDULER gebruikt de som
          van requests om te beslissen of een node ruimte heeft. Dit is je gegarandeerde vloer.
LIMIT   → het MAXIMUM dat de container mag gebruiken. Afgedwongen at runtime:
          CPU boven limit    → GETHROTTLED (vertraagd, niet gedood)
          memory boven limit → OOM-KILLED (container beëindigd, dan herstart)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0.25 van een core, gegarandeerd
          memory: "256Mi"
        limits:
          cpu: "500m"        # mag bursten tot 0.5 core, dan gethrottled
          memory: "512Mi"    # overschrijd dit → OOMKilled
```

## Hoe scheduling requests gebruikt

```text
Node heeft 4 CPU / 8Gi alloceerbaar.
Scheduler telt de REQUESTS op van al geplaatste Pods; een nieuwe Pod past alleen als zijn
requests nog in het restant passen. (Limits worden NIET gebruikt voor plaatsing.)
→ Requests te laag → node overcommitted, Pods vechten om resources.
→ Requests te hoog → verspilde capaciteit, Pods blijven op Pending (niets past).
```

## QoS-klassen (bepalen eviction-volgorde onder memory-druk)

```text
Guaranteed  → requests == limits voor ZOWEL cpu als memory (elke container)
              → als laatste geëvicteerd (hoogste prioriteit)
Burstable   → heeft requests maar die zijn < limits (of deels gezet)
              → geëvicteerd na BestEffort
BestEffort  → helemaal geen requests of limits
              → als EERSTE geëvicteerd wanneer de node weinig memory heeft
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # daadwerkelijk CPU/memory-gebruik
kubectl describe node <node>               # toegewezen resources vs capaciteit
```

## Praktische richtlijnen

```text
✓ Zet memory requests = limits voor voorspelbaar, OOM-veilig gedrag bij kritieke apps
✓ Zet CPU requests op de steady-state behoefte; CPU limits worden vaak weggelaten om bursting toe te staan
✓ Dimensioneer op basis van echt gebruik (kubectl top / metrics) — niet op gok
✓ Gebruik LimitRange / ResourceQuota om verstandige defaults per namespace af te dwingen
```

## Waarom het belangrijk is

Requests en limits zijn hoe Kubernetes eindige node-resources eerlijk en voorspelbaar deelt, dus het onderscheid en de gevolgen ervan begrijpen is essentiële performance- en betrouwbaarheidskennis. Het kerninzicht is dat ze verschillende doelen dienen: **requests** zijn een gegarandeerde reservering die de **scheduler** gebruikt om Pods te plaatsen (requests optellen om te beslissen of een node ruimte heeft, limits negerend), terwijl **limits** een runtime-plafond zijn dat per resource anders wordt afgedwongen — een **CPU**-limit overschrijden levert **throttling** op (vertraging), maar een **memory**-limit overschrijden zorgt dat de container **OOM-killed** en herstart wordt. Requests verkeerd instellen kost aan beide kanten echt: te laag en nodes raken overcommitted zodat Pods elkaar uithongeren; te hoog en capaciteit wordt verspild terwijl Pods op Pending blijven omdat niets past. De drie **QoS-klassen** — Guaranteed (requests gelijk aan limits), Burstable (requests onder limits), en BestEffort (niets gezet) — bepalen de eviction-volgorde onder memory-druk, waarbij BestEffort als eerste en Guaranteed als laatste wordt gedood, precies wat je moet begrijpen om kritieke workloads te beschermen. De praktische richtlijnen kennen (memory requests gelijk aan limits voor kritieke apps, dimensioneren op basis van echt gebruik via `kubectl top`, defaults afdwingen met LimitRange/ResourceQuota) verandert dit van theorie in gedegen capacity planning. Omdat verkeerde resource-configuratie een van de meest voorkomende oorzaken is van instabiliteit, verspilde uitgaven en Pending Pods in echte clusters, is het beheersen van requests, limits en QoS fundamenteel om efficiënte, stabiele Kubernetes-workloads te draaien.

Requests vs limits

Hoe scheduling requests gebruikt

QoS-klassen (bepalen eviction-volgorde onder memory-druk)

Praktische richtlijnen

Waarom het belangrijk is

Gerelateerde vragen