Aufbau eines automatisierten Testframeworks basierend auf Chaos Mesh und Argo
Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →
Chaos Mesh ist eine Open-Source-Chaos-Engineering-Plattform für Kubernetes. Obwohl sie umfangreiche Möglichkeiten zur Simulation abnormaler Systemzustände bietet, löst sie nur einen Teil des Chaos-Engineering-Puzzles. Neben der Fehlerinjektion umfasst eine vollständige Chaos-Engineering-Anwendung das Aufstellen von Hypothesen zu definierten stabilen Zuständen, das Durchführen von Experimenten in Produktionsumgebungen, die Validierung des Systems über Testfälle und die Automatisierung des Testings.
Dieser Artikel beschreibt, wie wir mit TiPocket, einem automatisierten Testframework, einen vollständigen Chaos-Engineering-Testzyklus für TiDB, unsere verteilte Datenbank, aufbauen.
Warum benötigen wir TiPocket?
Bevor wir ein verteiltes System wie TiDB in Produktion nehmen können, müssen wir sicherstellen, dass es robust genug für den täglichen Einsatz ist. Aus diesem Grund haben wir vor einigen Jahren Chaos Engineering in unser Testframework eingeführt. In unserem Testframework gehen wir wie folgt vor:
-
Beobachten der normalen Metriken und Entwickeln unserer Testhypothese.
-
Injizieren einer Liste von Fehlern in TiDB.
-
Ausführen verschiedener Testfälle zur Überprüfung von TiDB in Fehlerszenarien.
-
Überwachung und Sammlung von Testergebnissen zur Analyse und Diagnose.
Dies klingt nach einem soliden Prozess, den wir seit Jahren nutzen. Allerdings wächst mit der Entwicklung von TiDB auch der Testumfang. Wir haben mehrere Fehlerszenarien, gegen die Dutzende von Testfällen im Kubernetes-Testcluster laufen. Selbst mit Chaos Mesh zur Fehlerinjektion bleibt anspruchsvolle Arbeit übrig – ganz zu schweigen von der Herausforderung, die Pipeline zu automatisieren, um das Testing skalierbar und effizient zu gestalten.
Deshalb haben wir TiPocket entwickelt, ein vollautomatisiertes Testframework basierend auf Kubernetes und Chaos Mesh. Derzeit nutzen wir es hauptsächlich zum Testen von TiDB-Clustern. Dank TiPockets Kubernetes-freundlichem Design und erweiterbarer Schnittstelle können Sie jedoch mit der Kubernetes-Erstellungs- und Löschlogik problemlos andere Anwendungen unterstützen.
Funktionsweise
Basierend auf den obigen Anforderungen benötigen wir einen automatisierten Workflow, der:
Chaos-Injektion - Chaos Mesh
Fehlerinjektion ist das Kernstück des Chaos-Testings. In einer verteilten Datenbank können Fehler jederzeit und überall auftreten – von Node-Abstürzen über Netzwerkpartitionen und Dateisystemfehler bis hin zu Kernel-Panics. Hier kommt Chaos Mesh ins Spiel.
Derzeit unterstützt TiPocket folgende Arten von Fehlerinjektion:
-
Netzwerk: Simuliert Netzwerkpartitionen, zufälligen Paketverlust, Unordnung, Duplizierung oder Verzögerung von Verbindungen.
-
Zeitversatz: Simuliert die Uhrenabweichung des zu testenden Containers.
-
Kill: Beendet den angegebenen Pod, entweder zufällig in einem Cluster oder innerhalb einer Komponente (TiDB, TiKV oder Placement Driver (PD)).
-
I/O: Injiziert I/O-Verzögerungen in TiDBs Storage-Engine TiKV, um I/O-bezogene Probleme zu identifizieren.
Nach der Fehlerinjektion müssen wir uns der Verifizierung widmen. Wie stellen wir sicher, dass TiDB diese Fehler übersteht?
Überprüfung der Chaos-Auswirkungen: Testfälle
Um zu validieren, wie TiDB Chaos standhält, haben wir in TiPocket Dutzende von Testfällen implementiert, kombiniert mit verschiedenen Prüftools. Um Ihnen einen Überblick zu geben, wie TiPocket TiDB bei Ausfällen verifiziert, betrachten Sie folgende Testfälle. Diese konzentrieren sich auf SQL-Ausführung, Transaktionskonsistenz und Transaktionsisolierung.
Fuzz-Testing: SQLsmith
SQLsmith ist ein Tool, das zufällige SQL-Abfragen generiert. TiPocket erstellt einen TiDB-Cluster und eine MySQL-Instanz. Die zufällig generierten SQL-Anweisungen werden auf TiDB und MySQL ausgeführt, während verschiedene Fehler in den TiDB-Cluster injiziert werden. Abschließend werden die Ausführungsergebnisse verglichen. Werden Inkonsistenzen festgestellt, deuten diese auf potenzielle Systemprobleme hin.
Transaktionskonsistenztests: Bank und Porcupine
Bank ist ein klassischer Testfall, der den Überweisungsprozess in einem Banksystem simuliert. Unter Snapshot-Isolation muss sichergestellt sein, dass der Gesamtbetrag aller Konten jederzeit konsistent bleibt – selbst bei Systemausfällen. Abweichungen im Gesamtbetrag deuten auf potenzielle Systemprobleme hin.
Porcupine ist ein Linearisierbarkeitsprüfer für Go, der die Korrektheit verteilter Systeme testet. Er nimmt eine sequenzielle Spezifikation als ausführbaren Go-Code entgegen, zusammen mit einer nebenläufigen Historie, und bestimmt, ob die Historie bezüglich der Spezifikation linearisierbar ist. In TiPocket nutzen wir den Porcupine-Prüfer in mehreren Testfällen, um zu überprüfen, ob TiDB die Linearisierbarkeitsbedingung erfüllt.
Transaktionsisolierungstests: Elle
Elle ist ein Prüftool, das die Transaktionsisolierungsstufe einer Datenbank verifiziert. TiPocket integriert go-elle, die Go-Implementierung des Elle-Prüftools, um die Isolierungsstufe von TiDB zu validieren.
Dies sind nur einige der Testfälle, mit denen TiPocket die Korrektheit und Stabilität von TiDB überprüft. Weitere Testfälle und Verifizierungsmethoden finden Sie in unserem Quellcode.
Automatisierung der Chaos-Pipeline - Argo
Nun haben wir Chaos Mesh für Fehlerinjektion, einen TiDB-Cluster zum Testen und Methoden zur Validierung – doch wie automatisieren wir den Chaos-Testing-Prozess? Zwei Optionen bieten sich an: Wir könnten die Scheduling-Funktionalität in TiPocket implementieren oder die Aufgabe an existierende Open-Source-Tools delegieren. Damit sich TiPocket voll auf den Testteil konzentrieren kann, wählten wir die Open-Source-Variante. Dies führte uns in Kombination mit unserem All-in-K8s-Design direkt zu Argo.
Argo ist eine Workflow-Engine für Kubernetes. Seit Langem Open Source, hat es breite Aufmerksamkeit und Anwendung gefunden.
Argo hat mehrere Custom Resource Definitions (CRDs) für Workflows abstrahiert. Die wichtigsten sind Workflow Template, Workflow und Cron Workflow. So integriert sich Argo in TiPocket:
-
Workflow Template ist eine Vorab-Definition für jede Testaufgabe. Bei Testausführung können Parameter übergeben werden.
-
Workflow plant mehrere Workflow-Templates in unterschiedlicher Reihenfolge, die die auszuführenden Aufgaben bilden. Argo ermöglicht zudem Bedingungen, Schleifen und gerichtete azyklische Graphen (DAGs) in der Pipeline.
-
Cron Workflow ermöglicht die Planung von Workflows wie Cron-Jobs. Ideal für Szenarien, in denen Testaufgaben langfristig laufen sollen.
Der beispielhafte Workflow für unseren vordefinierten Bank-Test ist unten dargestellt:
spec:
entrypoint: call-tipocket-bank
arguments:
parameters:
- name: ns
value: tipocket-bank
- name: nemesis
value: random_kill,kill_pd_leader_5min,partition_one,subcritical_skews,big_skews,shuffle-leader-scheduler,shuffle-region-scheduler,random-merge-scheduler
templates:
- name: call-tipocket-bank
steps:
- - name: call-wait-cluster
templateRef:
name: wait-cluster
template: wait-cluster
- - name: call-tipocket-bank
templateRef:
name: tipocket-bank
template: tipocket-bank
In diesem Beispiel nutzen wir die Workflow-Vorlage und Nemesis-Parameter, um die spezifische Fehlerinjektion zu definieren. Sie können die Vorlage wiederverwenden, um mehrere Workflows für verschiedene Testfälle zu erstellen. Dadurch lassen sich zusätzliche angepasste Fehlerinjektionen in den Ablauf integrieren.
Neben den Beispiel-Workflows und Vorlagen von TiPocket ermöglicht das Design auch das Hinzufügen eigener Fehlerinjektions-Abläufe. Die Handhabung komplexer Logik durch programmierbare Workflows macht Argo entwicklerfreundlich und zur idealen Wahl für unsere Anwendungsfälle.
Nun läuft unser Chaos-Experiment automatisch. Doch was, wenn die Ergebnisse nicht unseren Erwartungen entsprechen? Wie lokalisieren wir das Problem? TiDB speichert vielfältige Monitoring-Daten, weshalb die Protokollsammlung essenziell ist, um Observability in TiPocket zu gewährleisten.
Visualisierung der Ergebnisse: Loki
In Cloud-nativen Systemen ist Observability entscheidend. Grundsätzlich erreichen Sie dies durch Metriken, Protokollierung und Tracing. Da TiPockets Haupttestfälle TiDB-Cluster evaluieren, sind Metriken und Protokolle unsere primären Quellen zur Problemdiagnose.
Auf Kubernetes ist Prometheus der De-facto-Standard für Metriken. Für die Protokollsammlung existiert jedoch kein einheitlicher Ansatz. Lösungen wie Elasticsearch, Fluent Bit und Kibana funktionieren gut, können aber Ressourcenkonflikte und hohe Wartungskosten verursachen. Wir entschieden uns für Loki, das Prometheus-ähnliche Protokollaggregationssystem von Grafana.
Prometheus verarbeitet TiDBs Monitoring-Daten. Da Prometheus und Loki ein ähnliches Label-System nutzen, lassen sich Metriken einfach mit entsprechenden Pod-Protokollen korrelieren, wobei ähnliche Abfragesprachen zum Einsatz kommen. Grafana unterstützt zudem Loki-Dashboards, sodass wir Monitoring-Daten und Protokolle parallel visualisieren können. Da Grafana bereits die integrierte Monitoring-Komponente in TiDB ist, kann Loki diese Infrastruktur wiederverwenden.
Alles im Verbund – TiPocket
Nun ist alles vorbereitet. Hier sehen Sie eine vereinfachte Darstellung von TiPocket:
Wie Sie sehen, steuert der Argo-Workflow alle Chaos-Experimente und Testfälle. Ein vollständiger Testzyklus umfasst typischerweise folgende Schritte:
- Argo erstellt einen Cron-Workflow, der den zu testenden Cluster, die zu injizierenden Fehler, den Testfall und die Aufgabendauer definiert. Bei Bedarf können Sie Case-Protokolle in Echtzeit einsehen.
-
Zum festgelegten Zeitpunkt startet ein separater TiPocket-Thread im Workflow, der den Cron-Workflow auslöst. TiPocket übergibt TiDB-Operator die Cluster-Definition. Dieser erstellt daraufhin den Ziel-TiDB-Cluster. Parallel sammelt Loki relevante Protokolle.
-
Chaos Mesh injiziert Fehler in den Cluster.
-
Anhand der genannten Testfälle validiert der Benutzer die Systemstabilität. Jeder Testfall-Fehler führt zum Workflow-Fehler in Argo, wodurch Alertmanager das Ergebnis an den konfigurierten Slack-Kanal sendet. Bei erfolgreichem Abschluss wird der Cluster bereinigt und Argo wartet auf den nächsten Test.
Dies ist der vollständige TiPocket-Workflow. .
Machen Sie mit
Chaos Mesh und TiPocket werden beide kontinuierlich weiterentwickelt. Wir haben Chaos Mesh an die CNCF gespendet und freuen uns darauf, dass sich weitere Community-Mitglieder uns anschließen, um ein vollständiges Chaos-Engineering-Ökosystem aufzubauen. Wenn Sie daran interessiert sind, besuchen Sie unsere Website oder treten Sie #project-chaos-mesh im CNCF Slack bei.