Kubernetes Requests und Limits legen fest, wie viel CPU und Memory Kubernetes für einen Container fest einplant und wo dessen Obergrenze liegt. Ohne diese Angaben verbraucht ein Container so viel, wie er will, und kann anderen Containern auf derselben Node die Ressourcen wegnehmen. Mit Requests und Limits im Manifest gibst du Kubernetes die Information, die es für Planung und Schutz braucht.
Ich betreibe Kubernetes-Cluster in Produktion und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben. Requests und Limits gehören zu den Einstellungen, bei denen zu knappe und zu großzügige Werte gleichermaßen Ärger machen, beides mit im Betrieb spürbaren Folgen. Eine Übersicht zu allen meinen Kubernetes-Beiträgen findest du auf der Seite Kubernetes.
Kubernetes Requests und Limits: der Unterschied in zwei Sätzen
Die Request ist nicht der gemessene Verbrauch, sondern der Wert, den du für die Planung festlegst: Kubernetes weist den Pod einer Node zu, die genau diesen Wert noch frei hat, und führt ihn dort als belegt. Grundlage dafür ist der gemessene Normalbedarf plus eine Sicherheitsmarge. Ob ein Container darüber hinausgehen kann, entscheidet nicht die Request, sondern die Ressource und das gesetzte Limit (Kubernetes-Dokumentation zum Ressourcenmanagement).
Das Limit ist die Obergrenze, und sie wirkt je Ressource unterschiedlich: Bei CPU wird der Container gedrosselt, sobald er sie erreicht, bei Memory beendet der Kernel den Prozess, wenn er darüber hinaus Speicher anfordert. Setzt du kein Limit, kann ein Container theoretisch die ganze Node für sich beanspruchen. Setzt du ein Limit über der Request, erlaubst du dem Container, kurzzeitig mehr zu verbrauchen, ohne dass er dafür fest eingeplant wird.
Ein Beispiel aus der Praxis: Eine Anwendung liegt im gemessenen Normalbetrieb bei etwa 0,4 CPU-Kernen und 450 MiB Memory. Mit etwas Marge setzt du die Request auf 0,5 Kerne und 512 MiB. Bei einem kurzen Lastpeak darf sie auf 1 CPU-Kern hochgehen. Das ist dein Limit. Kubernetes plant den Pod anhand der 0,5 Kerne ein, erlaubt ihm im Bedarfsfall aber den doppelten Verbrauch.
Was bei Überschreitung passiert: CPU-Throttling gegen Out-of-Memory
CPU und Memory verhalten sich an ihrem Limit unterschiedlich, und dieser Unterschied entscheidet oft über die richtige Fehlersuche. Überschreitet ein Container sein CPU-Limit, wird er nicht beendet, sondern gedrosselt: Der Kernel lässt ihm für den Rest eines Zeitfensters keine weitere Rechenzeit. Deine Anwendung läuft weiter, wird aber spürbar langsamer, ohne dass ein Fehler oder ein Neustart sichtbar wird.
Bei Memory gibt es diese sanfte Bremse nicht. Überschreitet ein Container sein Memory-Limit, beendet der Kernel den Prozess sofort mit einem Out-of-Memory-Fehler, kurz OOM-Kill. kubectl describe pod zeigt dir das als OOMKilled im letzten Zustand des Containers, danach startet Kubernetes ihn entsprechend seiner Restart Policy neu.
| Ressource |
Verhalten am Limit |
Sichtbar in kubectl |
| CPU |
Drosselung, keine Beendigung |
hohe Latenz, kubectl top zeigt Throttling nicht direkt |
| Memory |
sofortiger Kill des Prozesses |
OOMKilled im Container-Status, Neustart |
Für die Fehlersuche bedeutet das: Wird eine Anwendung ohne erkennbaren Fehler langsam, prüfe zuerst das CPU-Limit. Startet sie dagegen wiederholt neu, prüfe zuerst das Memory-Limit und die Events des Pods.
QoS-Klassen: wie Kubernetes deine Pods bei Engpässen sortiert
Aus deinen Requests und Limits leitet Kubernetes automatisch eine Quality-of-Service-Klasse ab, die entscheidet, welcher Pod bei einem Ressourcenengpass auf der Node als Erstes weichen muss.
| Klasse |
Bedingung |
Verhalten bei Engpass |
| Guaranteed |
Request gleich Limit für CPU und Memory in jedem Container |
wird zuletzt vertrieben |
| Burstable |
mindestens eine Request oder ein Limit gesetzt, aber nicht gleich |
wird nach BestEffort vertrieben |
| BestEffort |
keine Requests und Limits gesetzt |
wird zuerst vertrieben |
Wenn eine Node unter Speicherdruck gerät, entscheidet das Kubelet anhand dieser Klassen, welche Pods es zuerst beendet, um die Node stabil zu halten. Ein Pod in der Klasse Guaranteed ist damit der sicherste Kandidat für alles, was nicht ausfallen darf, kostet dich aber auch die Flexibilität eines Limits über der Request.
Die richtigen Werte finden statt raten
Requests und Limits aus dem Bauch heraus zu setzen, führt fast immer zu einem von zwei Fehlern: entweder zu großzügig, was Ressourcen auf der Node verschwendet, oder zu knapp, was zu Throttling und OOM-Kills führt. Beide Fehler lassen sich mit denselben Werkzeugen vermeiden.
Läuft in deinem Cluster ohnehin Prometheus, ist die P95-Nutzung von CPU und Memory über einen längeren Zeitraum die belastbarste Grundlage für deine Requests. Der Vertical Pod Autoscaler kann dieselbe Arbeit automatisieren: Im Recommender-Modus beobachtet er den tatsächlichen Verbrauch und schlägt Werte vor, ohne selbst etwas an deinen laufenden Pods zu ändern. Das ist der Modus, den ich in eigenen Clustern zuerst einsetze, denn er liefert Zahlen, bevor er automatisch eingreift.
Eine einzelne Messung reicht dabei nicht. Beobachte deine Anwendung über mehrere Tage und über einen echten Lasttest, denn eine ruhige Nacht sagt nichts über den Verbrauch am Monatsende.
CPU-Limits setzen oder weglassen?
In der Praxis hat sich eine Diskussion etabliert, die ich in meinen eigenen Clustern differenziert löse: CPU-Limits sind der Grund für viel Throttling, das auf den ersten Blick nicht erklärbar wirkt, weil kubectl top es nicht direkt anzeigt. Wer kein CPU-Limit setzt, riskiert dafür, dass eine einzelne Anwendung bei einem Bug die ganze Node für sich beansprucht. Eine allgemeingültige Antwort gibt es hier nicht: Wie stark sich ein CPU-Limit auswirkt, hängt vom Lastprofil ab, und wer den generellen Verzicht empfiehlt, verallgemeinert eine Beobachtung aus latenzkritischen Diensten auf alle Workloads.
Meine Faustregel: Memory-Limits setze ich immer, weil ein OOM-Kill sichtbar und beherrschbar ist. Bei CPU-Limits bin ich vorsichtiger und setze sie vor allem dort, wo mehrere Teams sich einen Namespace teilen und ich verhindern muss, dass eine Anwendung die anderen ausbremst. Auf isolierten, gut überwachten Workloads verzichte ich manchmal bewusst auf das CPU-Limit und verlasse mich auf eine passende Request.
So sieht ein Pod-Manifest mit Requests und Limits für beide Ressourcen aus:
apiVersion: v1
kind: Pod
metadata:
name: checkout-service
spec:
containers:
- name: checkout-service
image: registry.example.com/checkout-service:stable
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "256Mi"
Die Angabe 250m steht für 250 Millicpu, also ein Viertel eines CPU-Kerns. Memory gibst du in Mebibyte (Mi) oder Gibibyte (Gi) an, denn Bytes würden das Manifest nur unleserlich machen. In diesem Beispiel darf der Container doppelt so viel CPU nutzen wie angefordert, bekommt beim Memory aber keinen Spielraum. Der Pod landet damit in der Klasse Burstable: Der Speicher ist fest zugesagt, bei der CPU bleibt Luft nach oben.
LimitRange und ResourceQuota: Grenzen für den ganzen Namespace
Requests und Limits im einzelnen Pod zu setzen, ist die eine Hälfte der Aufgabe. Die andere Hälfte ist, dafür zu sorgen, dass niemand sie vergisst oder zu großzügig wählt. Dafür gibt es zwei Objekte auf Namespace-Ebene.
Eine LimitRange setzt Standardwerte für Requests und Limits, falls ein Manifest keine mitbringt, und kann zusätzlich Minimal- und Maximalwerte je Container erzwingen. Eine ResourceQuota begrenzt die Summe aller Requests und Limits im gesamten Namespace, zum Beispiel auf maximal 10 GiB Memory für alle Pods zusammen. In meinen Kundenprojekten setzen die Plattform-Teams beide Objekte standardmäßig in jedem neuen Namespace, damit ein vergessenes Limit nicht zum Problem für den ganzen Cluster wird. Wer diese Vorgaben zusätzlich technisch erzwingen will, etwa mit einer Policy-Engine wie Gatekeeper, verhindert von vornherein, dass ein Manifest ohne Requests überhaupt in den Cluster gelangt.
Häufige Fragen
Was ist der Unterschied zwischen Requests und Limits in Kubernetes?
Die Request ist der Wert, den Kubernetes zur Planung auf einer Node einrechnet und dort als belegt führt. Das Limit ist die Obergrenze für den tatsächlichen Verbrauch: Bei CPU greift eine Drosselung, bei Memory ein Abbruch des Prozesses. Zwischen Request und Limit darf ein Container frei schwanken.
Sollte ich für jeden Container CPU-Limits setzen?
Das kommt auf den Cluster an. In geteilten Namespaces mit mehreren Teams verhindert ein CPU-Limit, dass eine Anwendung die anderen ausbremst. Auf isolierten, gut überwachten Workloads ist der Verzicht auf ein CPU-Limit eine bewusste Entscheidung, die etwas Flexibilität bei Lastpeaks erlaubt.
Was bedeutet OOMKilled und wie vermeide ich es?
OOMKilled bedeutet, dass ein Container sein Memory-Limit überschritten hat und der Kernel ihn deshalb beendet hat. Vermeiden lässt sich das durch ein Memory-Limit aus einem realistischen Lasttest statt aus einer Schätzung, und durch die Frage, ob die Anwendung den Speicher überhaupt braucht oder ihn nur nicht wieder freigibt.
Wie finde ich die richtigen Werte für Requests und Limits?
Am belastbarsten sind gemessene Werte aus Prometheus über mehrere Tage und einen echten Lasttest, ergänzt durch den Vertical Pod Autoscaler im Recommender-Modus. Eine einzelne Momentaufnahme reicht dafür nicht aus.
Reichen Requests und Limits allein als Ressourcen-Steuerung im Namespace?
Nein. Für den ganzen Namespace ergänzt eine LimitRange Standardwerte und Grenzen je Container, während eine ResourceQuota die Summe aller Requests und Limits im Namespace begrenzt. Beide zusammen verhindern, dass ein einzelner vergessener Wert den ganzen Cluster belastet.
Wie du weitermachst
Requests und Limits sind die Grundlage für zwei Themen, die direkt daran anschließen: Skalierst du deine Anwendung automatisch, rechnet Kubernetes Autoscaling mit HPA mit genau diesen Requests. Und ob dein Pod überhaupt merkt, dass er unter Last leidet, entscheiden Liveness und Readiness Probes erklärt. Wer mehrere Teams in einem Cluster trennt, findet die passende Grundlage dazu in Kubernetes Namespaces richtig nutzen.
Mein Vorschlag für heute: Prüfe in einem deiner Namespaces mit kubectl describe pod, ob Requests und Limits überhaupt gesetzt sind, und vergleiche sie mit dem tatsächlichen Verbrauch über kubectl top pod. Die offizielle Referenz dazu findest du in der Kubernetes-Dokumentation zum Ressourcen-Management.
Ausführlich mit Rechenbeispiel, Overcommitment-Grafik und Fehlersuche steht das in Kapitel 8 meines Kubernetes-Praxisbuchs bei Rheinwerk.
