Wie Chaos Mesh Apache APISIX dabei hilft, die Systemstabilität zu verbessern

Inoffizielle Beta-Übersetzung

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

Wie Chaos Mesh Apache APISIX dabei hilft, die Systemstabilität zu verbessern

Apache APISIX ist ein Cloud-natives, hochleistungsfähiges und skalierbares Microservices-API-Gateway. Es ist eines der Top-Level-Projekte der Apache Software Foundation und bedient hunderte Unternehmen weltweit, indem es deren geschäftskritischen Datenverkehr verarbeitet – darunter aus den Bereichen Finanzwesen, Internet, Fertigung, Einzelhandel und Telekommunikation. Zu unseren Kunden zählen NASA, die Digitale Fabrik der Europäischen Union, China Mobile und Tencent.

Mit dem Wachstum unserer Community interagieren die Funktionen von Apache APISIX zunehmend mit externen Komponenten. Dadurch wird unser System komplexer und die Fehlerwahrscheinlichkeit steigt. Um potenzielle Systemausfälle zu identifizieren und Vertrauen in die Produktionsumgebung aufzubauen, führten wir das Konzept des Chaos Engineering ein.

Apache-APISIX-Architektur

In diesem Beitrag zeigen wir, wie wir Chaos Mesh nutzen, um unsere Systemstabilität zu verbessern.

Unsere Herausforderungen

Apache APISIX verarbeitet täglich mehrere zehn Milliarden Anfragen. Bei diesem Volumen haben unsere Nutzer folgende Probleme festgestellt:

• Szenario 1: Im Konfigurationszentrum von Apache APISIX – wenn unerwartet hohe Netzwerklatenzen zwischen etcd und Apache APISIX auftreten, kann Apache APISIX den Datenverkehr dann noch normal filtern und weiterleiten?

• Szenario 2: Wenn ein Knoten im etcd-Cluster ausfällt, der Cluster aber weiterhin normal läuft, wird ein Fehler bei der Interaktion des Knotens mit der Apache-APISIX-Admin-API gemeldet.

Obwohl Apache APISIX in Continuous Integration (CI) bereits viele Szenarien durch Unit-, End-to-End (E2E)- und Fuzz-Tests abdeckt, fehlte bisher die Interaktion mit externen Komponenten. Verhält sich das System bei Anomalien – etwa Netzwerkstörungen, Festplattenausfällen oder beendeten Prozessen – korrekt? Kann Apache APISIX angemessene Fehlermeldungen liefern? Kann es weiterlaufen oder sich selbst in einen normalen Betriebszustand zurückversetzen?

Warum wir Chaos Mesh gewählt haben

Um diese Nutzerszenarien zu testen und ähnliche Probleme vor dem Produktivgang zu entdecken, entschied sich unsere Community für Chaos-Tests mit Chaos Mesh.

Chaos Mesh ist eine Cloud-native Chaos-Engineering-Plattform mit umfassenden Methoden zur Fehlerinjektion in Kubernetes-Systemen. Sie deckt Fehler in Pods, Netzwerken, Dateisystemen und sogar im Kernel ab. So hilft sie Nutzern, Schwachstellen im System zu finden und sicherzustellen, dass es unkontrollierbare Situationen in der Produktionsumgebung bewältigen kann.

Wie Apache APISIX hat auch Chaos Mesh eine aktive Open-Source-Community. Wir wissen, dass eine lebendige Community stabilen Softwarebetrieb und schnelle Iterationen gewährleistet. Das macht Chaos Mesh noch attraktiver.

Wie wir Chaos Mesh in APISIX einsetzen

Chaos Engineering hat sich über reine Fehlerinjektion hinaus zu einer vollständigen Methodik entwickelt. Für unsere Chaos-Experimente definierten wir zunächst den normalen Betriebszustand („Steady State“) unserer Anwendung. Dann führten wir potenzielle Probleme ein, um die Systemreaktion zu beobachten. Verließ die Anwendung den stabilen Zustand, wurden die Probleme behoben.

Anhand der beiden genannten Szenarien zeigen wir nun konkret, wie wir Chaos Mesh in Apache APISIX nutzen.

Szenario 1

Wir führten ein Chaos-Engineering-Experiment in folgenden Schritten durch:

1. Wir haben Metriken identifiziert, um zu überprüfen, ob Apache APISIX ordnungsgemäß läuft. Im Test nutzten wir vorrangig Grafana zur Überwachung der Laufzeitmetriken von Apache APISIX. Wir extrahierten Vergleichsdaten aus Prometheus in der CI. Dabei verwendeten wir Requests pro Sekunde (RPS) für Routing/Forwarding und die etcd-Erreichbarkeit als Bewertungskriterien. Wir analysierten die Logs: Für Apache APISIX überprüften wir Nginx-Error-Logs auf Fehler und deren Übereinstimmung mit den Erwartungen.

2. Wir führten einen Kontrollgruppentest durch. Sowohl create route als auch access route waren erfolgreich, und die Verbindung zu etcd bestand. Wir protokollierten die RPS-Werte.

3. Wir fügten mit Network-Chaos eine Netzwerklatenz von fünf Sekunden hinzu und wiederholten den Test. Diesmal scheiterte set route, während get route erfolgreich war. Die etcd-Verbindung bestand weiterhin, und die RPS zeigten keine signifikanten Änderungen. Das Experiment entsprach unseren Erwartungen.

Hohe Netzwerklatenz zwischen etcd und Apache APISIX

Szenario #2

Nach dem gleichen Kontrollgruppentest führten wir Pod-Kill-Chaos ein und reproduzierten den erwarteten Fehler. Beim zufälligen Löschen einiger etcd-Knoten konnte APISIX mal eine Verbindung aufbauen, mal nicht. Die Logs zeigten zahlreiche Verbindungsabweisungen.

Beim Löschen des ersten oder dritten Knotens in der etcd-Endpunktliste funktionierte set route normal. Wurde jedoch der zweite Knoten gelöscht, gab set route den Fehler "connection refused" zurück.

Unsere Analyse zeigte: Die von APISIX genutzte etcd-Lua-API wählte Endpunkte sequenziell, nicht zufällig aus. Dadurch band sich jeder etcd-Client an genau einen Endpunkt, was bei Ausfällen zu anhaltenden Fehlern führte.

Nach der Behebung fügten wir der etcd-Lua-API einen Health Check hinzu, um Anfragen an ausgefallene Knoten zu vermeiden. Für den Fall kompletter etcd-Trennung implementierten wir einen Fallback-Mechanismus, um Log-Überflutung zu verhindern.

Fehlermeldung bei etcd-Knoteninteraktion

Unsere Zukunftspläne

Chaos-Tests in E2E-Simulationsszenarien

Aktuell identifizieren wir manuell Schwachstellen für Tests. Da wir in der CI testen, besteht keine Gefahr für Produktivumgebungen. Allerdings decken wir keine komplexen Realumgebungsszenarien ab.

Um mehr Szenarien abzubilden, planen wir, bestehende E2E-Tests um randomisierte Chaos-Experimente mit größerer Abdeckung zu erweitern.

Chaos-Tests für weitere Apache-APISIX-Projekte

Neben Apache APISIX selbst sollen künftig auch Projekte wie Apache APISIX Dashboard und Apache APISIX Ingress Controller Chaos-Tests integrieren.

Funktionen für Chaos Mesh erweitern

Bei der Chaos-Mesh-Implementierung fehlten temporär Funktionen wie Serviceauswahl für Netzwerklatenz oder Container-Port-Injection. Die APISIX-Community wird künftig an diesen Features mitwirken.

Ihr könnt gern zum Apache-APISIX-Projekt auf GitHub beitragen. Bei Interesse an Chaos Mesh: Tretet unserem Slack-Channel (#project-chaos-mesh) bei oder reicht Pull Requests/Issues im GitHub-Repository ein.