Kubernetes-Ressourcen effizient dimensionieren

Ein Deployment mit zu knapp bemessenen Ressourcen fällt oft nicht im Lasttest auf, sondern am Montagmorgen nach einem Release. Umgekehrt binden übergroße Requests Kapazität, die im Cluster bezahlt, aber nie genutzt wird. Kubernetes-Ressourcen effizient dimensionieren heißt deshalb nicht, möglichst niedrige Werte einzutragen. Es heißt, Verfügbarkeit, Performance und Cloud-Kosten auf Basis echter Betriebsdaten in ein belastbares Verhältnis zu bringen.

Für mittelständische Unternehmen ist das eine operative Aufgabe mit direkter Geschäftswirkung. Falsch dimensionierte Workloads verlängern Incident-Zeiten, behindern Skalierung und treiben die Infrastrukturkosten. Richtig gewählte Requests und Limits schaffen dagegen planbare Plattformen, schnellere Releases und mehr Spielraum für Produktentwicklung.

Warum die Ressourcendimensionierung in Kubernetes schwierig ist

Kubernetes plant Pods primär anhand ihrer Resource Requests ein. Ein CPU-Request von 500m reserviert keine fest garantierte Rechenzeit, signalisiert dem Scheduler aber den erwarteten Bedarf. Bei Memory ist die Lage strenger: Überschreitet ein Container sein gesetztes Limit, kann Kubernetes ihn beenden. Das Ergebnis ist häufig ein OOMKilled-Event und ein Neustart genau dann, wenn die Anwendung unter Druck steht.

Der entscheidende Punkt: Requests und Limits beschreiben nicht dasselbe. Ein zu hoher CPU-Request führt dazu, dass Nodes vermeintlich voll sind, obwohl deren reale Auslastung niedrig bleibt. Ein zu enges CPU-Limit kann dagegen Throttling verursachen. Die Anwendung erhält zwar ihren Platz im Cluster, verarbeitet Anfragen aber langsamer. Bei speicherintensiven Services können zu niedrige Memory-Limits zu wiederholten Neustarts führen, während überhöhte Werte die Node-Dichte reduzieren.

Eine pauschale Formel gibt es nicht. Ein Java-Service mit Heap, Metaspace und nativen Bibliotheken verhält sich anders als ein Go-Service, ein Node.js-Backend oder ein Batch-Worker. Auch ein API-Service mit gleichmäßiger Last braucht andere Sicherheitsreserven als ein E-Commerce-System mit Spitzen zu Kampagnenbeginn. Gute Dimensionierung beginnt daher mit dem tatsächlichen Laufzeitverhalten, nicht mit Standardwerten aus einem Helm-Chart.

Kubernetes-Ressourcen effizient dimensionieren: Von Messwerten zu Zielwerten

Der erste Schritt ist eine klare Bestandsaufnahme. Nicht jede Anwendung muss gleichzeitig optimiert werden. Priorität haben geschäftskritische Services, Workloads mit häufigen Restarts, Pods mit CPU-Throttling sowie Anwendungen, die auffällig viel reservierte, aber wenig genutzte Kapazität aufweisen. Gerade in gewachsenen Clustern liegen dort oft die größten Kosten- und Stabilitätshebel.

Betrachten Sie Metriken über einen ausreichend langen Zeitraum. Ein einzelner Arbeitstag ist selten repräsentativ. Sinnvoll sind mehrere Wochen inklusive Peak-Zeiten, Releases, Monatsläufen und geplanter Hintergrundverarbeitung. Entscheidend sind CPU-Nutzung, Speicherverbrauch, Restart-Häufigkeit, Latenzen, Fehlerraten und die Anzahl wartender oder nicht einplanbarer Pods.

Für den CPU-Request bietet sich meist ein Wert an, der den typischen hohen Bedarf abdeckt, ohne kurzfristige Spitzen vollständig vorab zu reservieren. Wie nah dieser Wert am oberen Perzentil liegen sollte, hängt vom Service ab. Bei einer latenzkritischen Checkout-API ist mehr Reserve sinnvoll als bei einem asynchronen Reporting-Worker. Ein CPU-Limit sollte bewusst gesetzt werden, nicht reflexhaft. Bei vielen Webanwendungen kann ein enges Limit durch Throttling mehr Schaden anrichten als es Kosten spart.

Beim Arbeitsspeicher ist die Sicherheitsmarge wichtiger. Memory lässt sich nicht wie CPU kurzfristig wegdrosseln. Der Request sollte das verlässlich erwartbare Niveau abbilden, das Limit genug Platz für realistische Spitzen lassen. Bei JVM-Anwendungen reicht der konfigurierte Heap dabei nicht als Grundlage. Container benötigen zusätzlich Speicher für Metaspace, Threads, Direct Memory, Caches und das Betriebssystem. Wer diese Anteile ignoriert, produziert OOMKills trotz vermeintlich großzügigem Heap.

Lastprofile statt Durchschnittswerte bewerten

Durchschnittswerte sind für die Kapazitätsplanung verführerisch und für die Produktionsrealität oft unbrauchbar. Ein Service mit durchschnittlich 200 MiB Speicherverbrauch kann bei bestimmten Anfragen regelmäßig 800 MiB benötigen. Wird sein Limit am Durchschnitt ausgerichtet, ist der nächste Neustart keine Überraschung, sondern eine eingeplante Schwachstelle.

Besser ist es, typische, hohe und außergewöhnliche Lastphasen voneinander zu trennen. Dazu gehören saisonale Peaks, Datenimporte, Crawler-Traffic, Marketingaktionen und Deployments mit parallelem Hochfahren neuer Pods. Die Frage lautet nicht nur: Wie viel verbraucht der Container im Normalbetrieb? Sondern auch: Was passiert bei Last, beim Skalieren und bei Fehlern abhängiger Systeme?

Requests, Limits und Autoscaling müssen zusammenpassen

Autoscaling korrigiert keine schlechte Grunddimensionierung. Der Horizontal Pod Autoscaler kann Pods hochskalieren, wenn Metrikschwellen erreicht werden. Seine Berechnung basiert jedoch häufig auf der CPU-Auslastung relativ zum Request. Ist der CPU-Request zu hoch, wirkt die Auslastung künstlich niedrig und die Skalierung setzt zu spät ein. Ist er zu niedrig, skaliert das System möglicherweise unnötig aggressiv.

Auch die maximale Replikazahl muss zur verfügbaren Clusterkapazität passen. Es hilft nicht, einen Service bis auf 50 Pods skalieren zu lassen, wenn die Nodes nur zehn zusätzliche Pods mit den hinterlegten Requests aufnehmen können. Dann bleiben Pods im Pending-Zustand, während die Antwortzeiten steigen. Cluster Autoscaler oder vergleichbare Mechanismen können das abfedern, brauchen aber Zeit und funktionierende Node-Pools.

Vertikale Anpassungen durch einen Vertical Pod Autoscaler sind für bestimmte Workloads sinnvoll, etwa für interne Services mit schwankendem, aber nicht extrem dynamischem Bedarf. In produktionskritischen Umgebungen sollte die Einführung kontrolliert erfolgen. Automatische Änderungen an Requests können Neustarts auslösen und müssen mit Deployment-Strategien, Verfügbarkeitszielen und Wartungsfenstern abgestimmt sein.

Die stabile Lösung besteht aus drei Ebenen: realistisch dimensionierte Pods, sinnvoll konfigurierte horizontale Skalierung und ausreichend verfügbare Node-Kapazität. Fehlt eine dieser Ebenen, verlagert sich das Problem lediglich. Ein zu groß gewählter Node-Pool kaschiert schlechte Pod-Requests, bis die Cloud-Rechnung sichtbar wird. Zu knappe Nodes machen selbst sauber konfigurierte Anwendungen unnötig fragil.

Die häufigsten Fehler im produktiven Betrieb

Ein verbreiteter Fehler sind identische Standardwerte für alle Services. 500m CPU und 512 MiB Memory mögen als Ausgangspunkt brauchbar sein, sagen aber nichts über tatsächliche Anforderungen aus. Besonders problematisch wird es, wenn Teams diese Werte aus Zeitdruck übernehmen und anschließend nicht mehr überprüfen.

Ebenfalls kritisch ist die Annahme, Limits seien immer ein Sicherheitsgewinn. Memory-Limits sind unverzichtbar, um einzelne Workloads einzugrenzen und Nodes zu schützen. CPU-Limits verlangen dagegen eine differenzierte Entscheidung. Bei Services mit strengen Latenzanforderungen kann CPU-Throttling teurer sein als die eingesparte Kapazität. Hier müssen SLOs und Kosten gemeinsam betrachtet werden.

Ein dritter Fehler ist die Optimierung ohne Beobachtbarkeit. Wer lediglich YAML-Dateien anpasst, ohne Verbrauch, Throttling, Restarts und Anwendungslatenz anschließend zu verfolgen, arbeitet auf Verdacht. Dimensionierung ist kein einmaliges Infrastrukturprojekt. Sie muss Teil des Betriebsmodells sein, genau wie Monitoring, Capacity Planning und Release-Management.

Ein belastbarer Prozess für Teams und Plattformbetrieb

In der Praxis bewährt sich ein wiederholbarer Zyklus. Zuerst werden Workloads nach Geschäftskritikalität und Auffälligkeit priorisiert. Danach werden Ressourcen- und Anwendungsmetriken ausgewertet, Hypothesen dokumentiert und Änderungen schrittweise ausgerollt. Nach jeder Anpassung folgt eine Beobachtungsphase unter realer Last. Erst wenn Latenz, Fehlerrate, Pod-Stabilität und Kostenentwicklung passen, werden die Werte als neuer Standard übernommen.

Dieser Prozess gehört in die Delivery-Strecke. Resource-Definitionen sollten versioniert, per Infrastructure as Code gepflegt und im Review behandelt werden. Bei neuen Services helfen verbindliche Mindeststandards: keine produktiven Deployments ohne Requests, nachvollziehbare Memory-Limits und Dashboards, die Nutzung und Reservierung gegenüberstellen. So wird aus einzelnen Optimierungsaktionen eine steuerbare Plattformpraxis.

devRocks verbindet diese technische Arbeit mit einem klaren Blick auf den Betrieb. Nicht die niedrigste Zahl im Manifest ist das Ziel, sondern eine Plattform, die unter Last planbar reagiert, Releases nicht ausbremst und deren Kosten nachvollziehbar bleiben.

Der beste Zeitpunkt für die erste Analyse ist vor dem nächsten Skalierungsproblem. Beginnen Sie mit den wenigen Workloads, die Kosten, Risiko oder Kundenerlebnis am stärksten beeinflussen - und machen Sie aus Messwerten verbindliche Betriebsentscheidungen.