Die Überwachung von Ressourcen in IT-Systemen war lange Zeit eine vergleichsweise einfache Aufgabe. Besonders in virtuellen Maschinenumgebungen basierte das Verständnis von Ressourcenauslastung oft auf festen Kapazitäten. Wenn die CPU-Auslastung nahe 100 Prozent lag, galt das als eindeutiger Hinweis auf Ressourcenknappheit. Innerhalb von Kubernetes aber verhält sich diese herkömmliche Logik ganz anders – und genau hier setzt der moderne Ansatz mit Pressure Stall Information (PSI) an, der ein viel besseres Verständnis von Ressourcenauslastung und Engpässen erlaubt. Kubernetes als Container-Orchestrierungssystem revolutionierte das Ressourcenmanagement grundlegend. Statt starrer Ressourcenallokationen gibt es mit Kubernetes flexible Ressourcenanfragen (Requests) und -grenzen (Limits), die ein dynamisches Teilen von Ressourcen auf einem Knoten erlauben.
Während früher ein fixer CPU-Anteil einem VM-Gast zugewiesen war, erlaubt Kubernetes jedem Container, je nach Verfügbarkeit mehr oder weniger Ressourcen zu nutzen. Das führt bereits an dieser Stelle zu einer entscheidenden Verwirrung: Ein Container, der mehr CPU nutzt als er angefragt hat, ist nicht zwangsläufig überfordert, sondern kann gerade von überschüssiger Kapazität profitieren. Umgekehrt bedeutet eine geringere Auslastung des angefragten Ressourcenvolumens nicht automatisch, dass kein Contention-Problem besteht. Diese neuen Mechanismen fordern ein Umdenken bei der Überwachung von Ressourcen. Es ist ein weit verbreiteter Fehler, einfach die CPU-Auslastung eines Containers mit seinem Ressourcen-Request zu vergleichen und daraus direkt auf Ressourcenknappheit zu schließen. Das mag bei festen Zuweisungen in VMs logisch sein, doch Kubernetes-Container entspannen sich über das Request-Level hinaus, solange Knotenkapazitäten verfügbar sind.
So kann eine CPU-Nutzung von 150 Prozent der beantragten Ressourcen durchaus unkritisch sein, solange andere Container ihren fairen Anteil bekommen. Ein Monitoring, das dieses Modell zugrunde legt, erzeugt leicht vermeintliche Problem-Signale, obwohl tatsächlich keine Ressourcenkonkurrenz besteht. Sicherlich bietet die Überwachung von Limits eine bessere Orientierung. CPU-Limits setzen harte Grenzen, und wenn ein Container die Grenze erreicht, wird er von der Linux-Kernel-Komponente komplettiert, indem seine CPU-Nutzung throttled wird. Throttling muss nicht direkt der Tod für die Performance sein, aber es kann durch abruptes Pausieren von Threads zu unerwünschten Latenzspitzen führen und deshalb für latenzkritische Anwendungen problematisch sein. Die Überwachung von CPU-Limits und insbesondere das Tracking von Throttle-Events kann bei gesetzten Limits Aufschluss darüber geben, dass ein Container mehr CPU-Ressourcen benötigt oder dass die Limits neu bewertet werden sollten.
Allerdings setzen viele moderne Kubernetes-Betriebe gar keine CPU-Limits, um derartige Engpässe und komplizierte Throttling-Effekte zu vermeiden. Die Linux-Kernel-Mechanismen sind hier ein zentrales Element: Die Completely Fair Scheduler (CFS) CPU-Sharing-Strategie ordnet CPU-Zeit proportional zu den angefragten CPU-Ressourcen zu. Dadurch bekommt jeder Container im Fall von Contention einen fairen Anteil – ohne dass explizite Limits notwendig sind. Das bedeutet auch, dass das Setzen von CPU-Limits oft mehr schadet als nützt, indem es das natürliche Bursting verhindert und CPU-Zyklen auf ungenutzten Ressourcen liegen bleiben. Da beim Scheduling nur Requests berücksichtigt werden, können Limits als reine Runtime-Beschränkungen betrachtet werden, die jedoch bei weitem nicht so aussagekräftig sind wie früher vermutet. Doch wie erkennt man nun echten Ressourcenmangel, wenn weder Vergleich zu Anfragen noch Limits verlässlich sind? Hier kommt Pressure Stall Information, kurz PSI, ins Spiel.
PSI ist ein seit Linux 4. 20 verfügbares Kernel-Feature, das direkt misst, wie oft Aufgaben bei CPU, Speicher oder IO Ressourcen blockiert werden. Dabei misst PSI nicht nur die Auslastung, sondern auch, wie lange Prozesse tatsächlich wegen Ressourcenmangel warten müssen. Dieser Wert ist essenziell, um echten Contention zu erfassen, statt nur eine scheinbar hohe Auslastung zu beobachten. Für Kubernetes bedeutet das eine Revolution in der Überwachungspraxis: PSI liefert konkrete Daten darüber, wie oft Container-Threads nicht sofort ausgeführt werden konnten, obwohl sie es wollten. Das ist viel aussagekräftiger als die reine CPU-Nutzung, weil es den Unterschied zwischen „Container nutzt CPU ausgelastet und problemlos“ und „Container versucht CPU zu nutzen, kann aber nicht, weil andere konkurrieren“ beschreibt. So lassen sich Fehlalarme vermeiden, bei denen bloß hohe Auslastungen ohne Auswirkungen falsch interpretiert wurden.
PSI-Werte werden mittlerweile vom Kubernetes-Tooling unterstützt, vor allem über cAdvisor und Kubelet-Metriken. Voraussetzung ist die Aktivierung der entsprechenden Feature-Gates und die Nutzung von cgroup v2 mit einem Linux-Kernel ab Version 4. 20. Über den Zugriff auf Metriken wie container_pressure_cpu_waiting_seconds_total lässt sich ermitteln, wie viele Sekunden ein Container in einem definierten Zeitraum (z. B. fünf Minuten) wegen CPU-Contention warten musste. Durch geeignete Prometheus-Abfragen werden daraus aussagekräftige Prozentzahlen, die in Dashboards visualisiert oder für Alerts genutzt werden können. Das Besondere an PSI ist, dass es auch zwischen verschiedenen Situationen unterscheidet. Zum Beispiel signalisiert ein hoher CPU-Pressure-Wert bei gleichzeitigem Erreichen der CPU-Limits, dass der Container durch seine Limitierung throttled wird.
Steigt CPU-Pressure aber bei nicht gesetzten Limits, bedeutet das einen echten Wettbewerb auf dem Knoten, bei dem der Container echte Ressourcenknappheit erfährt. Ebenso überzeugt PSI bei der Speicherüberwachung, da Memory Pressure frühzeitig anzeigt, wenn Prozesse auf Speicher warten oder häufig Garbage Collection und Pagefaults ausführen – oft bevor hinreichende Nutzungsschwellen oder OOM-Kills auftreten. Für Monitoring- und SRE-Teams ist PSI ein starkes Werkzeug, um Alarmierung und Troubleshooting klarer und zielgerichteter zu gestalten. Statt sich auf nutzergenerierte Metriken wie Auslastung oder Vergleich zu Requests zu stützen, ermöglicht PSI den Blick auf die tatsächliche Systembelastung und -kontention. So werden Fehlalarme reduziert und echte Performance-Engpässe frühzeitig erkannt. Im Zusammenspiel mit klassischen Metriken lassen sich komplexe Zustände noch besser erfassen.
Eine Kombination aus CPU-Usage, CPU-Limits, CPU-Pressure und Application-Latenz gewährt ein ganzheitliches Bild. Ein Szenario könnte sein, dass ein Pod hohe CPU-Auslastung zeigt, aber keine CPU-Pressure – ein Indiz für effiziente Verarbeitung. Oder der Pod zeigt moderate CPU-Auslastung, aber eine signifikante CPU-Pressure – klarer Hinweis auf Ressourcenkonflikte und Performance-Degradation. Auf Knotenebene erlaubt PSI, die Gesamtbelastung zu messen und so rechtzeitig Maßnahmen wie Clusterautoscaling oder Lastverteilung zu initiieren. Die Sichtbarkeit von PSI auf Container- oder Pod-Ebene fördert zudem eine präzise Ursachenanalyse, die nicht mehr auf Vermutungen basiert, sondern auf quantitativen Daten. Das führt zu besseren Betriebserfahrungen und optimaler Ressourcennutzung. In der Praxis bedeutet die Einführung von PSI in die Monitoring-Strategie einen bedeutsamen Schritt weg von antiquierten Metriken, die wenig über das tatsächliche Verhalten der Container aussagen.
PSI schafft Klarheit, vermeidet Fehlentscheidungen wegen falscher Signale und unterstützt eine ressourcenorientierte und performante Clusterbewirtschaftung. Entsprechend empfehlen Experten, bei der Gestaltung von Monitoring-Lösungen PSI-Metriken zu integrieren, CPU-Limits maßvoll oder gar nicht zu setzen und stattdessen auf Requests und PSI-basierte Contention-Erkennung zu setzen. Zusammenfassend lässt sich festhalten: Kubernetes verändert grundlegend, wie Ressourcen gemessen, bewertet und überwacht werden müssen. Alte Denkmuster basierend auf fixen Kapazitäten und statischer Auslastung sind nicht mehr zielführend. Moderne Systeme brauchen eine neue, differenzierte Betrachtung, bei der die erlebte Wartezeit durch Ressourcenknappheit im Vordergrund steht. PSI stellt genau dieses Instrument zur Verfügung und revolutioniert damit das Monitoring in containerisierten Umgebungen.
Unternehmen, die PSI einsetzen, profitieren von präziseren Alarmeinstellungen, weniger False Positives und tiefgehendem Einblick in Aktivitäten auf Pod- und Node-Ebene. Diese Transparenz ermöglicht proaktives Kapazitätsmanagement und nachhaltige Optimierung der Infrastruktur. Kubernetes-SREs und Entwickler sollten PSI daher unbedingt in ihren Monitoring-Stack integrieren, um die Herausforderungen moderner Cloud-Infrastrukturen souverän zu meistern.
