Kubernetes Requests und Limits richtig setzen

Falsch gesetzte Requests und Limits sind die haeufigste Ursache fuer Kubernetes-Probleme im Produktivbetrieb. Zu niedrige Requests fuehren zu Overcommitment und instabilen Nodes. Zu hohe Limits verschwenden Ressourcen und treiben Kosten hoch. Dieser Artikel zeigt, wie Sie die richtigen Werte finden.

TL;DR

• Requests bestimmen die Scheduling-Garantie -- setzen Sie sie auf den typischen Verbrauch Ihrer Anwendung (P50-P75).
• Memory Limits sollten nah an den Requests liegen (Faktor 1.0-1.5), CPU Limits koennen Sie oft weglassen.
• QoS-Klasse Guaranteed (Requests = Limits) fuer kritische Workloads, Burstable fuer den Rest.
• Nutzen Sie VerticalPodAutoscaler im Recommendation-Mode, um die richtigen Werte zu finden.

Was Requests und Limits bewirken

Pruefen Sie zuerst den aktuellen Ressourcenverbrauch eines Pods:

# Aktueller CPU/Memory-Verbrauch aller Pods im Namespace
kubectl top pods -n production

# Detailansicht mit Requests und Limits
kubectl describe node <node-name> | grep -A 5 "Allocated resources"

Jetzt die Grundlagen:

Requests sind eine Garantie. Der Scheduler platziert einen Pod nur auf einem Node, der genug freie Requests hat. Wenn ein Pod 500m CPU und 256Mi Memory anfordert, reserviert Kubernetes diese Ressourcen -- unabhaengig davon, ob der Pod sie gerade nutzt.

Limits sind eine Obergrenze. Ueberschreitet ein Container sein Memory-Limit, wird er per OOMKill beendet. Ueberschreitet er sein CPU-Limit, wird er gedrosselt (Throttling) -- aber nicht gekillt.

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: app
    image: myapp:2.1
    resources:
      requests:
        cpu: 250m      # 0.25 CPU Kerne garantiert
        memory: 256Mi   # 256 MiB RAM garantiert
      limits:
        cpu: 1000m      # Max 1 CPU Kern
        memory: 512Mi   # Max 512 MiB RAM -- darueber: OOMKill

Der entscheidende Unterschied: CPU vs. Memory

Dieser Punkt wird oft missverstanden:

Memory ist nicht komprimierbar. Wenn ein Node keinen freien Speicher hat, muss Kubernetes Pods evicten. CPU kann hingegen geteilt werden -- Pods werden langsamer, aber es crasht nichts.

Die drei QoS-Klassen

Kubernetes weist jedem Pod automatisch eine Quality-of-Service-Klasse zu. Diese bestimmt, welche Pods bei Ressourcenknappheit zuerst evicted werden:

Guaranteed -- Hoechste Prioritaet. Requests und Limits sind identisch fuer alle Container im Pod:

resources:
  requests:
    cpu: 500m
    memory: 512Mi
  limits:
    cpu: 500m       # = Request
    memory: 512Mi   # = Request

Burstable -- Mittlere Prioritaet. Mindestens ein Container hat Requests, aber Limits weichen ab oder fehlen:

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 1000m
    memory: 512Mi

BestEffort -- Niedrigste Prioritaet. Keine Requests und keine Limits gesetzt. Diese Pods werden bei Engpaessen zuerst gekillt.

Pruefen Sie die QoS-Klasse eines Pods:

kubectl get pod web-app -o jsonpath='{.status.qosClass}'

Konkrete Empfehlungen fuer die Praxis

Nach hunderten Deployments haben sich diese Faustregeln bewaehrt:

Memory: Eng setzen

Memory Requests auf den typischen Verbrauch (P50-P75 der letzten 7 Tage). Memory Limits maximal 1.5x der Requests. Grund: Ein Memory Leak soll den Pod toeten, nicht den ganzen Node.

# Typische Java-Anwendung mit 512 MiB Heap
resources:
  requests:
    memory: 768Mi    # Heap + Metaspace + Off-Heap
  limits:
    memory: 1Gi      # ~1.3x Request, Puffer fuer GC-Spitzen

CPU: Grosszuegiger -- oder gar kein Limit

CPU Requests auf den durchschnittlichen Verbrauch. CPU Limits sind umstritten. Viele erfahrene Teams setzen gar keine CPU Limits, weil Throttling schwer zu diagnostizieren ist und die Latenz unvorhersehbar verschlechtert.

# Option A: Mit CPU Limit
resources:
  requests:
    cpu: 250m
  limits:
    cpu: 2000m     # 8x Request -- grosszuegig fuer Burst

# Option B: Ohne CPU Limit (verbreitete Praxis)
resources:
  requests:
    cpu: 250m
  # Kein CPU Limit -- Pod kann burst, wird aber bei Contention
  # proportional zu seinen Requests eingeschraenkt

Richtwerte nach Workload-Typ

Die richtigen Werte finden

Raten Sie nicht -- messen Sie. Es gibt drei Methoden.

Methode 1: kubectl top und Prometheus

# Momentaufnahme
kubectl top pod -n production --sort-by=memory

# Mit Prometheus: P95 CPU der letzten 7 Tage
# PromQL:
# quantile_over_time(0.95, rate(container_cpu_usage_seconds_total{namespace="production"}[5m])[7d:1m])

Methode 2: Vertical Pod Autoscaler (VPA) im Recommendation-Mode

Der VPA analysiert den tatsaechlichen Verbrauch und gibt Empfehlungen -- ohne automatisch zu aendern:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-app-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: "Off"    # Nur Empfehlungen, keine automatischen Aenderungen

# Empfehlungen abrufen nach 24-48 Stunden
kubectl get vpa web-app-vpa -o jsonpath='{.status.recommendation}' | jq

Methode 3: Goldilocks

Goldilocks von Fairwinds erstellt automatisch VPA-Objekte fuer alle Deployments in einem Namespace und zeigt die Empfehlungen in einem Dashboard:

# Namespace labeln
kubectl label namespace production goldilocks.fairwinds.com/enabled=true

Typische Fehler

Fehler 1: Requests = Limits fuer alles. Das verschwendet massiv Ressourcen. Guaranteed QoS ist nur fuer wirklich kritische Pods sinnvoll (Datenbanken, Core-Services).

Fehler 2: Kein Memory Limit. Ein Memory Leak in einem Pod kann den gesamten Node destabilisieren. Setzen Sie immer ein Memory Limit.

Fehler 3: Copy-Paste aus Tutorials. Die resources-Werte aus Helm Charts und Tutorials sind Platzhalter. Messen Sie den tatsaechlichen Verbrauch Ihrer Anwendung.

Fehler 4: Requests zu niedrig, Limits zu hoch. Das fuehrt zu Overcommitment: Der Scheduler packt zu viele Pods auf einen Node, und bei Last evicted Kubernetes Pods.

LimitRange und ResourceQuota

Verhindern Sie, dass Teams ohne Requests und Limits deployen:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: production
spec:
  limits:
  - default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
    type: Container

FAQ

Sollte ich CPU Limits setzen oder weglassen?

Es kommt auf den Kontext an. Ohne CPU Limits kann ein Pod temporaer mehr CPU nutzen, was die Performance verbessert. In Shared Clusters mit vielen Teams sind CPU Limits sinnvoll, um Noisy Neighbors zu verhindern. In dedizierten Namespaces koennen Sie darauf verzichten.

Was passiert, wenn ich keine Requests setze?

Der Pod bekommt die QoS-Klasse BestEffort und wird bei Ressourcenknappheit als Erstes evicted. Ausserdem kann der Scheduler den Pod auf einen bereits ueberlasteten Node platzieren.

Wie erkenne ich CPU Throttling?

Prufen Sie die container_cpu_cfs_throttled_seconds_total Metrik in Prometheus. Ein hoher Wert bedeutet, dass der Container regelmaessig am CPU Limit gedrosselt wird. Erhoehen Sie das Limit oder entfernen Sie es.

Wie oft sollte ich Requests und Limits anpassen?

Pruefen Sie die Werte nach jedem groesseren Release und mindestens einmal pro Quartal. Traffic-Muster und Anwendungsverhalten aendern sich -- Ihre Ressourcenkonfiguration sollte das widerspiegeln.

Naechster Schritt: Aktivieren Sie den VPA im Recommendation-Mode fuer Ihre wichtigsten Deployments. Nach einer Woche haben Sie belastbare Daten, um Requests und Limits zu optimieren.

Weiterführende Artikel:

• Kubernetes OOM Kills vermeiden: Praxis-Guide
• Kubernetes HPA konfigurieren: Autoscaling Tutorial