Sollten Sie in Kubernetes-Produktionsumgebungen CPU-Limits verwenden?
Der Beitrag fragt im Grunde:
- Ist der Ratschlag „CPU-Limits nicht mehr verwenden“ noch gültig?
- Setzen Sie in der Produktion CPU-Limits ein?
Ja, die Mechanik stimmt nach wie vor. Ob Sie sie einsetzen sollten, hängt vom Workload und von der Cluster-Philosophie ab.
Was CPU-Limits tatsächlich bewirken
In Kubernetes steuert der CPU-Request das Scheduling, die CPU wird bei der Platzierung also garantiert. Das CPU-Limit ist dagegen eine harte Obergrenze über das CFS-Quota, den Linux Completely Fair Scheduler.
Wird das Limit erreicht, wird der Container hart gedrosselt.
Warum manche sagen „CPU-Limits nicht mehr verwenden“
Der Robusta-Artikel beschreibt reales Verhalten. Mit Limits werden Pods gedrosselt, obwohl der Node noch freie CPU hat, es gibt Latenzspitzen, und die Performance bei Lastspitzen wird unvorhersehbar.
Die Kernel-Mechanik hat sich nicht geändert, und ein Antwortender bestätigt das:
„Ja, immer noch gültig. Die beschriebene Mechanik hat sich nicht verändert.“
Bei Bursty-Workloads, also den meisten Webdiensten, schaden Limits mehr, als sie nützen.
Die Realität in der Produktion
Es geht hier um die Absicht hinter der Einstellung, und die Antwort lautet selten „immer“ oder „nie“.
Fall 1: Burstable Webdienste (die meisten Apps)
APIs, Frontends, Event-Consumer und typische SaaS-Workloads sind meist im Leerlauf, dann spitzenlastig, und sie profitieren davon, ungenutzte CPU ausleihen zu können.
Viele Cluster fahren deshalb mit gesetzten CPU-Requests und ohne CPU-Limits. Bei Memory ist das anders, denn Memory-Limits setzen Sie fast immer. CPU ist elastisch.
Fall 2: CPU-lastige Batch-Jobs
Datenverarbeitung, Videoencoding, ML-Workloads und CI/CD-Runner erzeugen konstante CPU-Last, hungern ihre Nachbarn aus und gewinnen nichts durch Bursting. Hier verdienen sich Limits ihren Platz, und ein Kommentator setzt sie gezielt für bestimmte Workloads oder CI-Runner ein.
Was ist mit QoS?
Jemand fragte:
gibt es echte Gründe für QoS in der Produktion?
QoS-Klassen sind relevant, wenn der Node unter Druck gerät. Request und Limit gleich groß ergibt Guaranteed, nur ein Request ergibt Burstable, und ohne beides landet der Pod bei BestEffort.
In den meisten realen Clustern ist Burstable völlig in Ordnung, Guaranteed ist für kritische Workloads sinnvoll, und BestEffort sollte man in der Produktion vermeiden. QoS taugt aber nicht als Grund, blind Limits hinzuzufügen, denn es spielt eher beim Memory-Eviction eine Rolle als beim CPU-Throttling.
Die versteckte Falle: Throttling ist keine Fairness
CPU-Limits „schützen“ den Cluster nicht. Sie drosseln nur den Container selbst und verteilen die Last nicht fair auf die Workloads, wie viele annehmen. Bei 30 % Cluster-CPU-Auslastung, dem Fall eines Kommentators, bewirken Limits nichts, außer möglicherweise die Bursts zu beeinträchtigen.
Was machen erfahrene Teams also wirklich?
Verbreitete Produktionsmuster im Jahr 2026:
Muster A: Modernes SaaS
- CPU-Requests gesetzt
- keine CPU-Limits
- Memory-Requests + Limits gesetzt
- HPA auf CPU oder Metriken
Dieses Muster sieht man heute in sehr vielen Clustern.
Muster B: Gemischte Workloads
Hier werden Limits selektiv eingesetzt:
- keine CPU-Limits für Webdienste
- CPU-Limits für:
- Batch-Jobs
- Datenverarbeitung
- CI-Runner
Muster C: Multi-Tenant-Cluster
Wenn sich mehrere Teams einen Cluster teilen und das Vertrauen gering ist:
- CPU-Limits als Leitplanken
- oft kombiniert mit ResourceQuota
Das ist Governance und keine Performance-Entscheidung.
Meine direkte Antwort
Ist der alte Ratschlag immer noch gültig? Ja. Und setze ich CPU-Limits ein? Für Bursty-Produktionsdienste nicht, für schwere, lang laufende CPU-Jobs schon. Memory-Limits und CPU-Requests setze ich immer. Zum Fehler wird es erst, wenn man Limits überall einsetzt, ohne Throttling verstanden zu haben.