Was ist der Unterschied zwischen CPU/Memory-requests und -limits, und wie beeinflussen sie Scheduling, Eviction und QoS?

Question

IT Interview Practice · Accepted Answer

**Requests** sind das, was einem Container *garantiert* wird (für Scheduling verwendet); **limits** sind die *Obergrenze*, die er nicht überschreiten darf (zur Laufzeit durchgesetzt). Zusammen bestimmen sie, wo Pods platziert werden, wie sie unter Druck gedrosselt oder getötet werden und welche **Quality-of-Service (QoS)**-Klasse ein Pod erhält.

## Requests vs. limits

```text
REQUEST → die für den Container RESERVIERTE Menge. Der SCHEDULER nutzt die Summe der
          requests, um zu entscheiden, ob ein Node Platz hat. Dies ist deine garantierte Untergrenze.
LIMIT   → das MAXIMUM, das der Container nutzen darf. Zur Laufzeit durchgesetzt:
          CPU über limit    → GEDROSSELT (verlangsamt, nicht getötet)
          memory über limit → OOM-KILLED (Container beendet, dann neu gestartet)
```

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      resources:
        requests:
          cpu: "250m"        # 0,25 eines Cores, garantiert
          memory: "256Mi"
        limits:
          cpu: "500m"        # darf auf 0,5 Core bursten, dann gedrosselt
          memory: "512Mi"    # dies überschreiten → OOMKilled
```

## Wie das Scheduling requests nutzt

```text
Node hat 4 CPU / 8Gi allokierbar.
Der Scheduler summiert die REQUESTS bereits platzierter Pods; ein neuer Pod passt nur, wenn seine
requests noch in das Verbleibende passen. (Limits werden für die Platzierung NICHT genutzt.)
→ requests zu niedrig setzen → Node überbucht, Pods kämpfen um Ressourcen.
→ requests zu hoch setzen → verschwendete Kapazität, Pods bleiben Pending (nichts passt).
```

## QoS-Klassen (entscheiden die Eviction-Reihenfolge unter Memory-Druck)

```text
Guaranteed  → requests == limits für BEIDE, cpu & memory (jeder Container)
              → wird zuletzt evicted (höchste Priorität)
Burstable   → hat requests, aber sie sind < limits (oder teilweise gesetzt)
              → wird nach BestEffort evicted
BestEffort  → gar keine requests oder limits
              → wird ZUERST evicted, wenn dem Node der Speicher ausgeht
```

```bash
kubectl describe pod app | grep -i qos    # QoS Class: Guaranteed/Burstable/BestEffort
kubectl top pods                           # tatsächliche CPU-/Memory-Nutzung
kubectl describe node <node>               # Allocated resources vs. capacity
```

## Praktische Empfehlungen

```text
✓ Bei kritischen Apps immer memory requests = limits für vorhersehbares, OOM-sicheres Verhalten
✓ CPU requests auf den Steady-State-Bedarf setzen; CPU limits oft weglassen, um Bursting zu erlauben
✓ Anhand realer Nutzung dimensionieren (kubectl top / metrics) — nicht raten
✓ LimitRange / ResourceQuota nutzen, um sinnvolle Defaults pro Namespace durchzusetzen
```

## Warum es wichtig ist

Requests und limits sind die Art, wie Kubernetes endliche Node-Ressourcen fair und vorhersehbar teilt, daher ist das Verständnis der Unterscheidung und ihrer Konsequenzen essenzielles Performance- und Zuverlässigkeitswissen. Die Kerneinsicht ist, dass sie unterschiedlichen Zwecken dienen: **requests** sind eine garantierte Reservierung, die der **scheduler** zur Platzierung von Pods nutzt (er summiert requests, um zu entscheiden, ob ein Node Platz hat, und ignoriert limits), während **limits** eine Laufzeit-Obergrenze sind, die pro Ressource unterschiedlich durchgesetzt wird — ein **CPU**-limit zu überschreiten führt zu **Drosselung** (Verlangsamung), aber ein **memory**-limit zu überschreiten lässt den Container **OOM-killed** und neu gestartet werden. requests falsch zu setzen hat reale Kosten auf beiden Seiten: zu niedrig, und Nodes werden überbucht, sodass Pods sich gegenseitig aushungern; zu hoch, und Kapazität wird verschwendet, während Pods Pending bleiben, weil nichts passt. Die drei **QoS-Klassen** — Guaranteed (requests gleich limits), Burstable (requests unter limits) und BestEffort (nichts gesetzt) — bestimmen die Eviction-Reihenfolge unter Memory-Druck, wobei BestEffort zuerst und Guaranteed zuletzt getötet wird, was genau das ist, was du verstehen musst, um kritische Workloads zu schützen. Die praktischen Empfehlungen zu kennen (memory requests bei kritischen Apps gleich limits setzen, anhand realer Nutzung über `kubectl top` dimensionieren, Defaults mit LimitRange/ResourceQuota durchsetzen) macht daraus aus Theorie eine solide Kapazitätsplanung. Weil Fehlkonfiguration von Ressourcen eine der häufigsten Ursachen für Instabilität, verschwendete Ausgaben und Pending-Pods in echten Clustern ist, ist die Beherrschung von requests, limits und QoS grundlegend für den Betrieb effizienter, stabiler Kubernetes-Workloads.

Requests vs. limits

Wie das Scheduling requests nutzt

QoS-Klassen (entscheiden die Eviction-Reihenfolge unter Memory-Druck)

Praktische Empfehlungen

Warum es wichtig ist

Ähnliche Fragen