Chaos Mesh Remake: Ein Schritt näher an Chaos as a Service

Inoffizielle Beta-Übersetzung

Diese Seite wurde von PageTurner AI übersetzt (Beta). Nicht offiziell vom Projekt unterstützt. Fehler gefunden? Problem melden →

Chaos-Engineering-Tools

Chaos Mesh ist eine cloud-native Chaos-Engineering-Plattform, die Chaos in Kubernetes-Umgebungen orchestriert. Mit Chaos Mesh können Sie die Resilienz und Robustheit Ihres Systems auf Kubernetes testen, indem Sie verschiedene Fehlertypen in Pods, Netzwerk, Dateisystem und sogar den Kernel einspielen.

Seit es als Open-Source-Projekt veröffentlicht und von der Cloud Native Computing Foundation (CNCF) als Sandbox-Projekt aufgenommen wurde, hat Chaos Mesh weltweit Mitwirkende angezogen und Benutzern beim Testen ihrer Systeme geholfen. Dennoch gibt es noch viel Verbesserungspotenzial:

• Die Benutzerfreundlichkeit muss verbessert werden. Einige Funktionen sind kompliziert zu bedienen. Wenn Sie beispielsweise ein Chaos-Experiment anwenden, müssen Sie oft manuell prüfen, ob das Experiment gestartet wurde.

• Es ist hauptsächlich für Kubernetes-Umgebungen gedacht. Da Chaos Mesh mehrere Kubernetes-Cluster nicht verwalten kann, müssen Sie Chaos Mesh für jeden Kubernetes-Cluster bereitstellen. Obwohl chaosd die Ausführung von Chaos-Experimenten auf physischen Maschinen unterstützt, sind die Funktionen recht eingeschränkt und die Kommandozeilenbedienung nicht benutzerfreundlich.

• Es unterstützt keine Plugins. Um ein angepasstes Chaos-Experiment anzuwenden, müssen Sie den Quellcode ändern. Darüber hinaus unterstützt Chaos Mesh nur Golang.

Zugegeben, Chaos Mesh ist eine erstklassige Chaos-Engineering-Plattform, aber es ist noch ein weiter Weg bis zur Bereitstellung von Chaos as a Service (CaaS). Deshalb haben wir beim TiDB Hackathon 2020 Änderungen an der Architektur von Chaos Mesh vorgenommen, um einen Schritt näher an CaaS heranzukommen.

In diesem Artikel erläutere ich, was CaaS ist, wie wir es mit Chaos Mesh erreichen, sowie unsere Pläne und die gewonnenen Erkenntnisse. Ich hoffe, dass unsere Erfahrungen Ihnen beim Aufbau Ihres eigenen Chaos-Engineering-Systems helfen.

Was ist Chaos as a Service?

Wie Matt Fornaciari, Mitbegründer von Gremlin, es ausdrückt, bedeutet CaaS, "dass Sie eine intuitive Benutzeroberfläche, Kundensupport, sofort einsatzbereite Integrationen und alles andere erhalten, was Sie benötigen, um innerhalb von Minuten mit dem Experimentieren zu beginnen."

Aus unserer Sicht sollte CaaS Folgendes bieten:

• Eine einheitliche Konsole für die Verwaltung, in der Sie die Konfiguration bearbeiten und Chaos-Experimente erstellen können.

• Visualisierte Metriken, um den Experimentstatus zu sehen.

• Operationen zum Anhalten oder Archivieren von Experimenten.

• Einfache Interaktion. Sie können Objekte per Drag-and-Drop verschieben, um Ihre Experimente zu orchestrieren.

Einige Unternehmen haben Chaos Mesh bereits an ihre eigenen Bedürfnisse angepasst, wie NetEase Fuxi AI Lab und FreeWheel, und machen es so zu einem Modell für CaaS.

Entwicklung von Chaos Mesh in Richtung CaaS

Basierend auf unserem Verständnis von CaaS haben wir die Architektur von Chaos Mesh während des Hackathons verfeinert, einschließlich verbesserter Unterstützung für verschiedene Systeme und besserer Beobachtbarkeit. Sie können unseren Code in wuntun/chaos-mesh und wuntun/chaosd einsehen.

Refactoring des Chaos Dashboards

Die aktuelle Architektur von Chaos Mesh eignet sich für einzelne Kubernetes-Cluster. Das Chaos Dashboard, die Weboberfläche, ist an eine bestimmte Kubernetes-Umgebung gebunden:

Chaos-Mesh-Architektur

Bei dieser Neuentwicklung haben wir Chaos Dashboard von der Hauptarchitektur entkoppelt, um die Verwaltung mehrerer Kubernetes-Cluster zu ermöglichen. Wenn Sie Chaos Dashboard außerhalb des Kubernetes-Clusters bereitstellen, können Sie Cluster über die Weboberfläche hinzufügen. Bei einer Bereitstellung innerhalb des Clusters erhält es Clusterinformationen automatisch über Umgebungsvariablen.

Sie können Chaos Mesh (technisch gesehen die Kubernetes-Konfiguration) in Chaos Dashboard registrieren oder chaos-controller-manager per Konfiguration anweisen, sich bei Chaos Dashboard zu melden. Chaos Dashboard und chaos-controller-manager interagieren über CustomResourceDefinitions (CRDs). Bei CRD-Ereignissen ruft chaos-controller-manager chaos-daemon auf, um das entsprechende Chaos-Experiment durchzuführen. Somit steuert Chaos Dashboard Experimente durch CRD-Operationen.

Refactoring von chaosd

chaosd ist ein Toolkit für Chaos-Experimente auf physischen Maschinen. Bisher war es nur ein Befehlszeilentool mit eingeschränkten Funktionen.

chaosd: Ein Chaos-Engineering-Befehlszeilentool

Beim Refactoring haben wir chaosd um RESTful-API-Unterstützung erweitert und seine Dienste verbessert, sodass es Chaos-Experimente durch Parsen von CRD-formatieren JSON- oder YAML-Dateien konfigurieren kann.

chaosd kann sich nun per Konfiguration bei Chaos Dashboard registrieren und regelmäßige Heartbeats senden. Dadurch kann Chaos Dashboard den Status der chaosd-Knoten verwalten. Sie können chaosd-Knoten auch direkt über die Weboberfläche hinzufügen.

Zudem kann chaosd jetzt Chaos-Experimente zeitgesteuert ausführen und Lebenszyklen verwalten – das vereinheitlicht die Benutzererfahrung für Kubernetes und physische Maschinen.

Mit dem neuen Chaos Dashboard und chaosd sieht die optimierte Chaos-Mesh-Architektur wie folgt aus:

Optimierte Chaos-Mesh-Architektur

Verbesserte Beobachtbarkeit

Eine weitere Optimierung betrifft die Beobachtbarkeit – insbesondere die Bestätigung erfolgreicher Experimente.

Vorher mussten Sie Metriken manuell prüfen. Bei einem StressChaos-Experiment in einem Pod mussten Sie beispielsweise den Pod betreten, um den stress-ng-Prozess zu suchen und dann CPU-/RAM-Auslastung mit top-Befehlen zu überprüfen.

Um dies zu vereinfachen, integrieren wir jetzt node_exporter in chaos-daemon und chaosd zur Erfassung von Knotenmetriken. In Kubernetes-Clustern deployen wir zusätzlich kube-state-metrics in Kombination mit cadvisor. Prometheus und Grafana speichern und visualisieren die Metriken – so können Sie den Experimentstatus einfach überprüfen.

Weitere Optimierungsbedarfe

Metriken verfolgen drei Hauptziele:

• Bestätigung der Chaos-Injektion

• Beobachtung der Chaos-Auswirkungen auf Dienste mit periodischer Analyse

• Reaktion auf unerwartete Chaos-Ereignisse

Dafür benötigt das System Metriken zu Experimentdaten, Basis-Metriken und Experimentereignissen. Hier besteht bei Chaos Mesh noch Optimierungsbedarf:

• Experimentdaten-Metriken (z.B. exakte Latenzzeit bei Netzwerklatenz-Experimenten oder spezifische Last bei Workload-Simulationen)

• Experimentereignisse (Kubernetes-Ereignisse für Erstellung, Löschung und Ausführung von Experimenten)

Ein gutes Beispiel für solche Metriken liefert Litmus.

Weitere Vorschläge für Chaos Mesh

Aufgrund der begrenzten Zeit während des Hackathons konnten wir nicht alle Pläne abschließen. Hier sind einige unserer Vorschläge, die die Chaos-Mesh-Community in Zukunft in Betracht ziehen könnte.

Orchestrierung

Ein geschlossener Regelkreis des Chaos Engineerings umfasst vier Schritte: Chaos erkunden, Schwachstellen im System identifizieren, Ursachen analysieren und Verbesserungsfeedback geben.

Geschlossener Regelkreis des Chaos Engineerings

Allerdings konzentrieren sich die meisten Open-Source-Chaos-Engineering-Tools derzeit nur auf die Erkundung und bieten kein praktisches Feedback. Basierend auf der verbesserten Observability-Komponente können wir Chaos-Experimente in Echtzeit überwachen sowie Ergebnisse vergleichen und analysieren.

Mit diesen Ergebnissen könnten wir einen geschlossenen Regelkreis realisieren, indem wir eine weitere wichtige Komponente hinzufügen: die Orchestrierung. Die Chaos-Mesh-Community hat bereits ein Workflow-Feature vorgeschlagen, das es ermöglicht, Chaos-Experimente einfach zu orchestrieren und Rückrufe durchzuführen oder Chaos Mesh bequem mit anderen Systemen zu integrieren. Sie können Chaos-Experimente in der CI/CD-Phase oder nach einem Canary-Release durchführen.

Die Kombination von Observability und Orchestrierung schafft einen geschlossenen Feedback-Zyklus für Chaos Engineering. Wenn Sie beispielsweise einen Netzwerk-Latenztest von 100 ms auf einem Pod starten würden, könnten Sie die Latenzänderung mit der Observability-Komponente beobachten und die Pod-Verfügbarkeit über PromQL oder andere DSL-basierte Orchestrierung prüfen. Falls der Dienst nicht verfügbar wäre, könnten Sie schlussfolgern, dass der Dienst bei einer Latenz ≥ 100 ms nicht verfügbar ist.

Aber 100 ms ist nicht der Schwellenwert Ihres Dienstes; Sie müssen wissen, welche maximale Latenz Ihr Dienst tolerieren kann. Durch die Orchestrierung des Werts im Chaos-Experiment erfahren Sie, welcher Schwellenwert für Ihre Service-Level-Objectives erforderlich ist. Zudem erkennen Sie die Dienstleistung unter verschiedenen Netzwerkbedingungen und ob diese Ihren Erwartungen entspricht.

Datenformat

Chaos Mesh verwendet CRDs, um Chaos-Objekte zu definieren. Wenn wir CRDs in JSON-Dateien konvertieren könnten, wäre die Kommunikation zwischen Komponenten möglich.

Bezüglich des Datenformats verarbeitet und registriert chaosd lediglich CRD-Daten im JSON-Format. Wenn ein Chaos-Tool CRD-Daten verarbeiten und sich selbst registrieren kann, kann es Chaos-Experimente in verschiedenen Szenarien durchführen.

Plugins

Chaos Mesh bietet nur begrenzte Plugin-Unterstützung. Sie können ein neues Chaos nur durch Registrierung eines CRD in der Kubernetes-API hinzufügen. Dies führt zu zwei Problemen:

• Plugins müssen in Golang entwickelt werden, der gleichen Sprache wie Chaos Mesh selbst.

• Der erweiterte Code muss in das Chaos-Mesh-Projekt eingebunden werden. Da Chaos Mesh keinen Sicherheitsmechanismus wie den Berkeley Packet Filter (BPF) bietet, könnte das Einbinden von Plugin-Code zusätzliche Risiken verursachen.

Für umfassende Plugin-Unterstützung müssen wir neue Methoden zur Plugin-Integration erforschen. Da Chaos Mesh Chaos-Experimente im Kern auf CRD-Basis durchführt, erfordert ein Chaos-Experiment lediglich das Generieren, Überwachen und Löschen von CRDs. Dazu haben wir mehrere vielversprechende Ansätze:

• Entwicklung eines Controllers oder Operators zur Verwaltung von CRDs.

• Zentrale Verarbeitung von CRD-Ereignissen und Operationen über HTTP-Callbacks. Diese Methode nutzt nur HTTP-APIs ohne Golang-Pflicht. Beispiel: Whitebox Controller.

• Einsatz von WebAssembly (Wasm). Bei Aufruf der Chaos-Experimentlogik wird einfach das Wasm-Programm ausgeführt.

• Nutzung von SQL zur Abfrage des Chaos-Experimentstatus. Da Chaos Mesh auf CRDs basiert, können Sie mit SQL auf Kubernetes zugreifen. Beispiele sind Presto-Connector und osquery-Erweiterung.

• SDK-basierte Erweiterungen wie Chaos Toolkit.

Integration mit anderen Chaos-Tools

Für reale Systeme kann ein einzelnes Chaos-Engineering-Tool kaum alle Anwendungsfälle abdecken. Deshalb macht die Integration mit anderen Chaos-Tools das Chaos-Engineering-Ökosystem leistungsfähiger.

Es gibt zahlreiche Chaos-Engineering-Tools auf dem Markt. Die Kubernetes-Implementierung von Litmus basiert auf PowerfulSeal, während die Container-Implementierung auf Pumba basiert. Kraken konzentriert sich auf Kubernetes, AWSSSMChaosRunner auf AWS und Toxiproxy auf TCP. Es gibt auch kombinierte Projekte basierend auf Envoy und Istio.

Um die verschiedenen Chaos-Tools zu verwalten, benötigen wir möglicherweise ein einheitliches Muster wie den Chaos Hub.

Stimmen aus der Community

Hier möchten wir zeigen, wie ein führendes Cybersicherheitsunternehmen in China – ebenfalls ein Chaos-Mesh-Nutzer – die Plattform an seine Bedürfnisse anpasst. Die Anpassungen umfassen drei Bereiche: physische Knoten, Container und Anwendungen.

Physischer Knoten

• Unterstützung der Skriptausführung auf physischen Servern. Über CRDs lässt sich das Skriptverzeichnis konfigurieren, Skripte werden via chaos-daemon ausgeführt.

• Simulation von Neustart, Herunterfahren und Kernel-Panic mittels angepasster Skripte.

• Deaktivierung der Netzwerkschnittstelle (NIC) über angepasste Skripte.

• Erzeugung häufiger Kontextwechsel mit sysbench zur Simulation des "Noisy Neighbor"-Effekts.

• Abfangen von Systemaufrufen des Containers mittels BPF-seccomp. Dies erfolgt durch Übergabe und Filterung von PIDs.

Container

• Zufällige Änderung der Deployment-Replikate zur Überprüfung von Traffic-Anomalien.

• Einbettung basierend auf CRD-Objekten: Ingress-Objekte in Chaos-CRDs füllen, um Interface-Drosselung zu simulieren.

• Einbettung basierend auf CRD-Objekten: Cilium-Netzwerkrichtlinien in Chaos-CRDs füllen, um Netzwerkschwankungen zu simulieren.

Anwendung

• Unterstützung für benutzerdefinierte Jobs. Aktuell injiziert Chaos Mesh Chaos via chaos-daemon, was keine Garantie für faire Scheduling-Verteilung bietet. Als Lösung kann chaos-controller-manager direkt Jobs für verschiedene CRDs erstellen.

• Ausführung von Newman in benutzerdefinierten Jobs zur zufälligen Änderung von HTTP-Parametern. Dies implementiert Chaos-Experimente auf HTTP-Schnittstellen, wie sie bei Nutzerfehlverhalten auftreten.

Zusammenfassung

Traditionelle Fehlertests zielen auf bestimmte, als kritisch eingeschätzte Systemstellen ab. Oft handelt es sich um eine Behauptung: Ein spezifischer Zustand erzeugt ein spezifisches Ergebnis.

Chaos Engineering ist leistungsfähiger, weil es hilft, "unbekannte Unbekannte" zu entdecken. Durch die Exploration in einem breiteren Bereich vertieft Chaos Engineering das Systemverständnis und fördert neue Erkenntnisse zutage.

Zusammenfassend möchten wir einige unserer persönlichen Gedanken und Praxiserfahrungen zu Chaos Engineering und Chaos Mesh teilen. Unser Hackathon-Projekt ist noch nicht produktionsreif, aber wir hoffen, damit etwas Licht auf CaaS zu werfen und einen vielversprechenden Fahrplan für Chaos Mesh zu entwerfen. Wenn Sie daran interessiert sind, Chaos as a Service aufzubauen, treten Sie unserem Slack bei (#project-chaos-mesh)!