Mit standard Framework

Loadtesting als Day-2-Operations von Container Lösungen

- Olaf von Voss, Ferdi Güran

k6.io ist ein Open-Source Framework das sich zusammen mit unseren Ergänzungen, schnell und einfach für Smoke- und Last-Tests von Cloud-Native Deployments nutzen lässt. In diesem Artikel stellen wir einen exemplarischen Weg vor, wie k6.io helfen kann, einen fiktiven Test zu konfigurieren, bzw. durchzuführen. Unser erweitertes SetUp ist dabei sowohl zur einmaligen Systemabnahme als auch dauerhaft, während eines Produkt-Lifecycles einsetzbar… und für jeden frei verfügbar!

Wie kann eine Cloud-Native Lösung, welche auf Kubernetes/OpenShift läuft, auf Herz und Nieren getestet werden? Sicher, Kubernetes selbst bietet von Hause aus eine ganze Reihe von Mechaniken, mit denen Ressourcen sich quasi selbst überwachen können: Readiness / Liveliness, Healthchecks, CustomResourceDefinitions, Lifecycle Policies und vieles Andere mehr.

Aber was ist mit einem vollwertigen Last- oder Abnahmetest als Vorbereitung auf den tatsächlichen Betrieb in Produktion? im Gegensatz zu (minimalen) Funktionstests sollte ein Deployment vor der Produktivsetzung auch unter realistischer, wenn auch simulierter, Last alle nötigen Tests bestehen.

Diesen Prozess jedes Mal aufs Neue manuell anzuschieben ist das eine Problem. Ein anderes ist die Frage, nach dem kontinuierlichen Testen im Rahmen von Day-2-Operations. In beiden Fällen kommt hier das k6.io Framework ins Spiel, einem Open-Source Werkzeug für Performance Tests unter Kubernetes.
Zunächst ist es wichtig, einige zentrale Begriffe im Kontext von Softwaretests zu klären. Was ist ein Smoke Test, was verbirgt sich unter Begriffen wie Last- oder auch Performance-Tests?

Testmethoden

Smoke Test

Zum sogenannten Smoke-Test kann man sich folgendes Bild vorstellen: Jemand hat ein Bastelprojekt, ein eigenes Transistorradio beispielsweise, fertiggestellt und schaltet es nun zum ersten Mal ein: Falls es nun knallt und sich das Radio mit einer Rauchwolke verabschiedet, hat es den sogenannten Smoke-Test nicht bestanden.
Ein solcher Test ist also eine Art Funktionstest mit minimaler Last. Übersetzt in Cloud-Native Software dient der Test dazu festzustellen ob die Lösung nach dem Deployment wie erwartet funktioniert. Ebenfalls nützlich ist ein Smoke-Test bei neu eingeführten Funktionalitäten: Laufen die neuen Bestandteile wie gewünscht?

Dem gegenüber klären Last-, bzw. Performance-Tests die Frage, wie sich ein (Software-)System unter einer gewissen Last, z.B. parallelen Anfragen von einer großen Menge User pro Sekunde, verhält. Diese Tests sind zum einen wichtig, um zu überprüfen, ob sich das Deployment auch unter realen Bedingungen, sprich unter Last, noch performant und zuverlässig verhält. Zum anderen liefern diese Tests wichtige Indikatoren um SLA / SLO im Betrieb planen zu können.

Load Test

Während der Smoke Test die Software funktional unter minimaler Last testet, erzeugt der Loadtest eine künstliche Grundlast. Diese basiert idealerweise auf einem realistischen Sizing und dessen Tests finden auf einer zumindest produktionsnahem Infrastruktur statt.
Und genau hier kann einiges schief gehen, wenn das System oder die Anwendung nicht resilient konzipiert wurde. So werden parallel viele Operationen und viele Benutzer emuliert, die sich an vordefinierte Muster halten (Userverhalten, einander bedingende Operationen, etc.).

Eine gute Lasttest-Strategie kann entscheidend sein um sicher zu stellen, dass eine Anwendung die Nutzung im realen Alltag bzw. auch unter Spitzenlast überlebt.

Ein geeignetes Werkzeug für Kubernetes Anwendungen

Um das Thema nun etwas mit Leben zu füllen, wollen wir einen einfachen Weg vorstellen, wie man Smoke- und Last-Tests als Deploymentabnahme und/oder dauerhafte Testlösung mit einer Cloud-Nativen Kubernetes Lösung ausrollen und ausführen kann: Das k6.io Framework als Open-Source Werkzeug für Performance Tests bietet eine komfortable und sehr einfach zu handhabende Ausgangsbasis.
Dabei ist eines ganz wichtig: Wir wollen auch in die Brennkammer der Tests schauen. Ohne korrekte Visualisierung liefern die Rohdaten nur wenig Kontext und machen somit eine schnelle Testauswertung schwierig. In unserem Beispiel nutzen wir daher einfache aber visuell ansprechende Dashboards auf Basis von Kibana und Elasticsearch (ebenfalls Open-Source).

Use Case

Nehmen wir an, dass wir eine webbasierte Dokumentenlösung namens CrocoDoc auf Kubernetes haben, die intern entwickelt und ausgerollt wird.

Auf CrocoDoc greifen täglich 200-500 Mitarbeiter gleichzeitig zu. Diese User erstellen täglich mehrere Dokumente mit Titel und Datum als Metadaten. Im weiteren Verlauf werden die neuen Dokumente auch aktualisiert bzw. abgerufen.
Um dieses Szenario mit einem k6.io Lasttest überprüfen zu können, reicht folgendes Script bereits aus:

Script

Zuvor muss natürlich das k6.io Framework lokal installiert werden, was mit folgender Anleitung schnell und unkompliziert gelingt: https://k6.io/docs/get-started/installation/

Test lokal ausführen

Test in Kubernetes ausführen

Da in einem echten Lasttest von verschiedenen Punkten aus (also verteilt) getestet werden muss, macht dieser lokale Test nur bedingt Sinn. Für einen produktiven Lasttest können wir das skizzierte Test-Beispiel jetzt nahtlos auf eine Kubernetes Umgebung inklusive eines übersichtlichen Dashboards für alle Testläufe und Szenarien adaptieren.
Die Anleitung dazu findet ihr hier —> https://github.com/deepshore/k6-testkit-resources

Dashboard by DeepOps

Als Ergebnis erhalten wir eine visuell aufbereitete und übersichtliche Auswertung unseres verteilten k6 Lasttests innerhalb des Kubernetes Clusters:

kibana_dash_k6

Fazit

Mit dem richtigen Werkzeug kann man relativ schnell einen Umfangreichen Smoke-, Integrations- oder einen dauerhaften Lasttest in einer Kubernetesumgebung einrichten.
Da alles in Manifestform abgelegt ist, erspart man sich das installieren von ggf. teuren und/oder aufwändig zu konfigurierenden Testtools.
Ein weiterer Vorteil ist, die Unabhängigkeit von den Saas-Fliegenfängern (Software as a service), da sich dass Setup vollständig unter der eigenen Kontrolle befindet. Egal ob in Azure, GCP, AWS oder OnPremises.

Alle nötigen Ressourcen für die o.g. Beschreibung finden Sie hier (auf Englisch): Deepshore K6 Testkit Resources

Teilen