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:

• CPU-Request → Scheduling (CPU wird bei der Platzierung garantiert).
• CPU-Limit → harte Obergrenze über das CFS-Quota (Linux Completely Fair Scheduler).

Wird das Limit erreicht, wird der Container gedrosselt. Nicht verlangsamt. Gedrosselt.

💥 Warum manche sagen „CPU-Limits nicht mehr verwenden“

Der Robusta-Artikel beschreibt reales Verhalten. Mit Limits:

• Pods werden gedrosselt, obwohl der Node noch freie CPU hat
• Latenzspitzen
• Unvorhersehbare Performance bei Lastspitzen

Die Kernel-Mechanik hat sich nicht geändert. Ein Antwortender bestätigt das:

„Ja, immer noch gültig. Die beschriebene Mechanik hat sich nicht verändert.“

Bei Bursty-Workloads (die meisten Webdienste) schaden Limits mehr, als sie nützen.

🧠 Die Realität in der Produktion

Nicht „immer“ oder „nie“. Es geht um die Absicht.

Fall 1 — Burstable Webdienste (die meisten Apps)

APIs, Frontends, Event-Consumer, typische SaaS-Workloads: meist im Leerlauf, spitzenlastig, profitieren eher davon, ungenutzte CPU auszuleihen.

Viele Cluster fahren mit:

• ✅ gesetzten CPU-Requests
• ❌ keinen CPU-Limits

Bei Memory ist das anders: Memory-Limits setzen Sie fast immer. CPU ist elastisch.

Fall 2 — CPU-lastige Batch-Jobs

Datenverarbeitung, Videoencoding, ML-Workloads, CI/CD-Runner: konstante CPU-Last, ausgehungerte Nachbarn, kein Vorteil durch Bursting. Hier verdienen sich Limits ihren Platz; 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 == Limit → Guaranteed
• nur Request → Burstable
• keins von beidem → 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. Aber QoS ist kein Grund, blind Limits hinzuzufügen; es spielt eher beim Memory-Eviction eine Rolle als beim CPU-Throttling.

🚨 Die versteckte Falle: Throttling ≠ Fairness

CPU-Limits „schützen“ den Cluster nicht. Sie drosseln nur den Container selbst; sie verteilen die Last nicht fair auf die Workloads, wie viele annehmen. Bei 30 % Cluster-CPU-Auslastung (der Fall eines Kommentators) bewirken Limits nichts außer potenziell 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

Heute extrem verbreitet.

Muster B — Gemischte Workloads

• keine CPU-Limits für Webdienste
• CPU-Limits für:
  • Batch-Jobs
  • Datenverarbeitung
  • CI-Runner

Selektiver Einsatz.

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

Governance-getrieben, nicht Performance-getrieben.

🎯 Meine direkte Antwort

Immer noch gültig? Ja.

Setze ich CPU-Limits ein?

• Nicht für Bursty-Produktionsdienste.
• Ja, für schwere, lang laufende CPU-Jobs.
• Memory-Limits setze ich immer.
• CPU-Requests setze ich immer.

Der Fehler liegt nicht darin, Limits zu verwenden. Der Fehler ist, sie überall einzusetzen, ohne Throttling zu verstehen.