Bei Lasttests in Kubernetes-Umgebungen geht es darum, ob eine containerisierte Anwendung unter Last die Erwartungen an Antwortzeit und Skalierung erfüllt. Weil Auto Scaling und Load Balancing jeden Lauf verändern, braucht ein belastbarer Test eine konkrete Risikofrage und eine Laborumgebung, in der beides zurückgefahren ist. Entwicklung, Operations und QA müssen dafür Metriken, Logs und Anwendungswissen zusammenbringen, allein schafft das keine Abteilung.
Das Wichtigste in Kürze
- Ein Lasttest ohne vorher formulierte Frage ist laut Stephan Schwarz verschwendete Lebenszeit, weil am Ende keine Entscheidung über ein Risiko daraus folgt.
- In jedem System steckt ein Bottleneck, und nach dem Beheben wartet das nächste; Lasttests in Kubernetes-Umgebungen zeigen, welches gerade limitiert.
- CPU und RAM sind selten die Ursache von Performance-Problemen in Kubernetes, häufiger fehlerhaftes Caching, ein externer OIDC-Provider, Datenbanken, Session-Handling oder Firewalls.
- Viele Teams setzen Requests und Limits für ihre Container gar nicht oder nicht valide, weil ohne Lasttest niemand weiß, wie sich die Software unter Last verhält.
- Lasttests in der CI/CD-Pipeline sind die Kür. Für infrastrukturlastige Projekte reicht zunächst ein Ende-zu-Ende-Smoke-Test, der Latenzmetriken als Testergebnis mitschreibt.
Lasttests in Kubernetes-Umgebungen brauchen zuerst eine Frage
Lasttests in Kubernetes-Umgebungen lohnen sich nur, wenn vorher klar ist, welche Frage sie beantworten sollen. Stephan Schwarz nennt einen Lasttest, der gemacht wird, damit einer gemacht wurde, „potenziell verschwendete Lebenszeit“. Aus dem Ergebnis soll eine Entscheidung folgen, sonst bleibt eine Zahl in einem Report.
Die Fragen, die Stephan meint, drehen sich um Risiko. Nehmen wir das Risiko in Kauf? Wie hoch ist es überhaupt, und worin besteht es? Lässt es sich mitigieren, und mit welchen Mitteln? Ist eine Mitigation definiert, prüft der nächste Lasttest, ob sie hält. Erst diese Kette macht aus einem Testlauf eine Grundlage für Entscheidungen.
Was heißt Performance überhaupt?
Performance heißt, dass Erwartungen erfüllt werden. Diese Erwartungen sind je Unternehmen verschieden, und oft merkt eine Organisation erst beim ersten Lasttest, dass intern niemand dasselbe darunter versteht. Alle sagen „muss performant sein“, aber was das in Sekunden oder Fehlerraten bedeutet, hat keiner festgelegt.
Stephan bringt ein Beispiel: Ist eine schnelle Fehlermeldung für den Kunden besser als vier, fünf oder zehn Sekunden Wartezeit auf eine valide Antwort? Die Antwort darauf hängt vom Geschäft ab. Dazu gehört die zweite Frage, welches Risiko das Unternehmen bewusst akzeptiert.
Warum machen so wenige Teams Lasttests?
Weil ein Team allein das Momentum dafür selten aufbaut. Stephan Schwarz sieht in Kundenprojekten meistens dasselbe Bild: Die Entwicklungsabteilung will testen, oder die QA sagt „das müssten wir mal machen“, und dann passiert nichts. Für einen belastbaren Lasttest braucht es die Expertise des Operations-Teams, des Plattform-Teams und manchmal eine Freigabe vom C-Level.
Dazu kommt der Aufwand. Eine Testumgebung aufbauen, Abhängigkeiten klären, Lastgeneratoren bereitstellen, Ergebnisse mit mehreren Abteilungen deuten. Das ist kein Nachmittag, und Stephan sagt offen, dass er versteht, warum das selten gemacht wird.
Fahrt gewinnt das Thema typischerweise nach einem Postmortem. Etwas ist ausgefallen, Kunden haben es gemerkt, und Lasttests stehen plötzlich in den Top 3 der Action Items. Besser wäre, vorher anzufangen.
Welche Testumgebung eignet sich für Lasttests in Kubernetes?
Die Umgebung folgt aus der Frage. Wer wissen will, wie eine containerisierte Anwendung unter CPU-Last skaliert, baut ein Laborsetup: entweder nur den Container oder einen eigenen Kubernetes-Cluster, auf dem sonst nichts läuft. Danach stellt sich die Frage nach den Infrastrukturabhängigkeiten. Nimmt der Test die Datenbank auf dem Produktionscluster oder eine eigene im Laborcluster?
Gegen die Produktionsumgebung zu testen, ist ebenfalls legitim. Manche Abhängigkeiten existieren aus guten Gründen nur in Prod und lassen sich in Staging nicht nachbauen. Wer das tut, benennt die Risiken und nimmt sie bewusst in Kauf.
Dahinter steckt ein Trade-off, aus dem niemand herauskommt. Je labormäßiger das Setup, desto weniger hat es mit dem zu tun, was später wirklich läuft.
Kubernetes macht zusätzlich die Wiederholbarkeit schwer. Stephan erinnert an den Spruch, der Einstein zugeschrieben wird (und wohl nicht von ihm stammt), nach dem zweimal dasselbe Tun auch dasselbe Ergebnis bringen sollte. In einem Kubernetes-Cluster ist schon das zweimal Dasselbe-Tun schwierig, weil Load Balancer und Autoscaling ständig eingreifen. Seine Empfehlung für den Anfang: Autoscaling und Load Balancing so weit wie möglich zurückfahren. Außer die Skalierung selbst ist die Frage, dann bleibt sie drin.
Der Lastgenerator muss mitskalieren
Die Anforderungen an einen Lastgenerator sind überschaubar. Das Werkzeug soll die Protokolle der Anwendung sprechen, Metriken ausgeben, den Test fahren und skalieren. Der letzte Punkt wird in Kubernetes zum Pflichtkriterium, weil die getestete Workload selbst hochskaliert. Skaliert der Generator nicht mit, ist er der limitierende Faktor und misst am Ende sich selbst.
Werkzeuge gibt es viele, Stephan nennt Artillery, Locust und k6. Kunden haben meistens einen Observability-Stack, der Logs und Metriken in ein Grafana-Dashboard bringt. Eine Lastgenerator-Farm, die bereitsteht, fehlt dagegen fast immer. In Vanilla-Kubernetes kommt so etwas nicht von Haus aus mit.
Stephans erster Lasttest 2018 lieferte miserable Zahlen. Er fragte sich, warum sein Service so schlecht war, bis er merkte, dass er vom eigenen Notebook testete. Das Gerät war schlicht nicht dafür gebaut, so viele Sessions parallel zu öffnen. Ein Lasttest prüft immer das ganze Konstrukt, den Generator eingeschlossen.
Was sind typische Ursachen für Performance-Probleme in Kubernetes?
Die Ursachen sind bunt, und reine Ressourcen gehören selten dazu. RAM nachschieben oder eine Node dazustellen, das alte Rezept, hilft nach Stephans Erfahrung in den seltensten Fällen.
Was er gesehen hat: ein Caching, das nicht sauber implementiert war. Eine externe Abhängigkeit, die niemand auf dem Schirm hatte, konkret ein ausgelagerter OIDC-Provider für die Authentifizierung, der nicht auf die Last ausgelegt war. Das System selbst hätte gekonnt, die Anmeldung nicht. Dazu Datenbank-Server, Session-Handling, Firewalls.
Genau deshalb braucht ein Lasttest alles an Know-how, was im Unternehmen zu finden ist. Vorher weiß niemand, wo es hakt, und keine Abteilung kann die Suche allein stemmen.
Das Bottleneck ist immer da
Jedes System hat ein Bottleneck. Wer es noch nicht gefunden hat, hat deshalb keins weniger. Und wer es behebt, bekommt das nächste, wie bei einer Hydra. Stephan nennt das den Normalzustand.
Das Team muss wissen, welches Bottleneck gerade limitiert. Dann kann es reagieren, wenn mehr Kunden kommen: Hardware fürs nächste Jahr planen oder in der Cloud rechtzeitig nachprovisionieren. Ohne diesen Befund wartet eine Organisation nur darauf, dass etwas passiert.
Dev und Ops sind unterschiedlich sozialisiert
Lasttests scheitern oft an der Grenze zwischen Entwicklung und Betrieb, und Stephan Schwarz erklärt das mit Sozialisierung. Er kommt selbst aus dem Operations, aus einem lokalen Rechenzentrum, in dem die oberste Regel lautete: bloß keine Änderung. Jede Änderung gefährdet das SLA, und Ausfälle sind für Ops-Menschen das Schlimmste. „Never touch a running system“ heißt es nicht ohne Grund. Für Entwickler gilt das Gegenteil, ihr Job sind Features, und Features sind Veränderungen.
Dazu kommt Silo-Denken. Stephan hat den Satz gehört: Wir entwickeln hier nur, und wenn die Anwendung nicht läuft, ist das ein Betriebsproblem. Stephan fragt dann zurück, ob der Betrieb als Team gemeint ist oder der Betrieb als Unternehmen. Im zweiten Fall stimmt der Satz.
Ein Lasttest ist deshalb Team-Effort. Operations hat die Metriken und Logs, die Entwickler kennen die Anwendung, die QA stellt die Testfragen. Sitzen alle drei an einem Tisch, passiert das, wofür Stephan brennt: Ops zeigt die Daten vom letzten Lauf, QA erklärt den Test, die Developer finden die Stelle im Code. Daraus entstehen Optimierungen, die weiter reichen als zwei zusätzliche CPUs.
Ein Lasttest ist auch kein Einmalprojekt. Ein Lauf liefert eine Vermutung, woran es liegt. Die Mitigation muss beweisen, dass sie wirkt, also fährt das Team den Test erneut. Am Ende versteht die ganze Firma ihr Produkt besser, auch das Management. Es sieht dann etwa, dass 10 Prozent langsamere Antworten für einen Kunden in Ordnung sind, weil der ohnehin cacht.
Gehören Lasttests in die CI/CD-Pipeline?
Die Integration in die Entwicklungspipeline nennt Stephan die Kür, und er glaubt nicht, dass jedes Team sie braucht. Wer ein infrastrukturlastiges Projekt mit vielen Abhängigkeiten betreibt, kann dort ansetzen. Solche Projekte haben ohnehin einen Smoke-Test, der Ende zu Ende läuft. Erfasst dieser Test zusätzlich die Metriken und notiert sie als Testergebnis, sieht das Team nach jeder Infrastrukturänderung, ob die Latenz steigt oder sinkt.
Wichtiger als die Pipeline ist Stephan etwas Einfacheres: dass Teams in Kubernetes-Umgebungen überhaupt adäquate Requests und Limits für ihre Container setzen. In vielen Projekten fehlen sie oder sind nicht valide gesetzt. Das ist kein Vorwurf, sagt er. Ein Entwicklungsteam kann nicht wissen, wie sich die Software unter Last verhält, solange niemand getestet hat. Und das Operations-Team hat zwar Metriken und Methoden, aber kaum Bezug zur Anwendung.
Anfangen heißt Momentum erzeugen
Der erste Schritt ist eine Liste von Fragen. Techniker, QA-Ingenieure und Operations Engineers haben meist ein Gefühl dafür, wo es klemmen könnte. Diese Vermutungen werden zu Fragen und zu benannten Risiken, etwa „ich könnte mir vorstellen, dass hier unser limitierender Faktor liegt“.
Mit dieser Liste geht das Team ins Management und macht Werbung. Das Argument liegt bereit: Wir wissen nicht, wo unser Bottleneck ist, also warten wir darauf, dass etwas passiert.
„Wenn ich mein Produkt nicht teste, dann macht es mein Kunde.“
(Stephan Schwarz)
Das Management darf sich auch anders entscheiden. Wenn SLAs und Verträge das hergeben, kann ein Unternehmen das Risiko tragen. Für Stephan ist das in Ordnung, solange es bewusst entschieden wurde. Wer dagegen einfach gegen eine Testinstanz schießt, ohne zu wissen warum, beantwortet damit noch keine Frage. Sein Tipp: Risiken transparent machen, Fragen transparent machen, über Abteilungen hinweg ins Gespräch kommen und so das Momentum aufbauen. Anders geht es seiner Erfahrung nach nicht.
