Von Traefik zu APISIX: Horizon Robotics' Erkundung im Bereich Ingress Controller

In der Automobilindustrie vollziehen die meisten Unternehmen den Übergang zum autonomen Fahren und zu neuen Energieformen. Insbesondere im Bereich des autonomen Fahrens haben die Unternehmen erhebliche Ressourcen investiert, um die Entwicklung und das Training von autonomen Fahrzeugmodellen abzuschließen.

In diesem Prozess stellt sich die Frage, wie die Stabilität und Effizienz des Geschäfts gewährleistet werden kann, während das Produkt schnell weiterentwickelt wird.

Dieser Artikel wirft einen Blick auf die KI-Entwicklungsplattform von Horizon Robotics, um zu sehen, wie das API-Gateway Apache APISIX und der Ingress Controller dem Entwicklungsteam von Horizon Robotics geholfen haben, diesen Schmerzpunkt zu lösen.

Gateway-Vergleich

Einschränkungen von Traefik

Vor der Verwendung des APISIX Ingress Controllers wurde der Ingress Controller Traefik 1.x im Geschäftssystem eingesetzt, jedoch gab es dabei mehrere Probleme.

Traefik 1.x konfiguriert Routing-Regeln über Ingress, und einige Plugins müssen durch das Hinzufügen von Annotationen konfiguriert werden. Auf diese Weise können Plugins nur für alle Regeln unter dem aktuellen Ingress hinzugefügt werden, und es ist keine feinere Konfiguration möglich.
Traefik 1.x unterstützt keine visuelle Konfiguration spezifischer Regeln und kann nicht direkt einen bestimmten Dienst durch den Zugriff auf die Anfrage-URL über den Browser ansteuern.
Die Standardkonfigurationsdatei (ConfigMap) von Traefik hat nur wenige Attribute, und viele Standardkonfigurationen müssen über die offizielle Dokumentation vorgenommen werden. Einige Parameter stimmen nicht mit der NGINX-Standardkonfiguration überein, was die Wartung erschwert.

Als Reaktion auf die oben genannten Probleme entschied sich das technische Team von Horizon Robotics, den Ingress Controller auszutauschen. Zu Beginn des Auswahlprozesses erwog das Team, Traefik auf Version 2.0 zu aktualisieren, um die Probleme zu lösen. Da jedoch auch ein neues CRD verwendet werden musste und die Migrationskosten hoch waren, mussten auch andere Ingress-Controller-Lösungen in Betracht gezogen werden.

Vorteile des APISIX Ingress Controllers

In der frühen Auswahlphase verglichen wir hauptsächlich Apache APISIX, Kong und Envoy. Andere Lösungen konnten jedoch mehr oder weniger die Anforderungen der bestehenden Szenarien in Bezug auf Funktionalität oder Leistung nicht erfüllen, mit Ausnahme von APISIX Ingress. Daher entschieden wir uns schließlich für APISIX Ingress. Neben einigen allgemeinen Funktionen interessierten uns vor allem die folgenden Punkte.

Reichhaltige Plugins: Die Plugins sind ökologisch gut ausgestattet, und alle von APISIX unterstützten Plugins können deklarativ mit apisix-ingress-controller konfiguriert werden. Die Plugins können für einen einzelnen Backend unter ApisixRoute angepasst werden.
Visuelle Konfiguration: Mit APISIX Dashboard kann jede apisix route eingesehen werden. Wenn dieselbe Domain in mehreren namespaces oder YAML-Dateien konfiguriert ist, kann das Pfadpräfix in Verbindung mit APISIX Dashboard durchsucht werden, um Konflikte schnell zu lokalisieren.
Feingranulare Überprüfung: Der APISIX Ingress Controller überprüft die in der CRD deklarierten Ressourcen. Wenn ein nicht existierender Dienst in der CRD deklariert wird, wird die Fehlermeldung im event von ApisixRoute gespeichert, und die Änderung tritt nicht in Kraft, was einige Probleme durch Fehlbedienung verringern kann.
Reichhaltige Funktionen: APISIX unterstützt Hot-Update und Hot-Plugins, Proxy-Anfrage-Rewriting, mehrere Authentifizierungsmethoden, Mehrsprachen-Plugin-Entwicklung und viele weitere Funktionen. Weitere Informationen finden Sie unter APISIX-Funktionen.
Aktive Community: Im Vergleich zu anderen Open-Source-Communities hat APISIX viele aktive Maintainer und Mitwirkende auf Slack, GitHub und der Mailingliste.
Hohe Leistung: Wie aus der folgenden Grafik ersichtlich ist, liegt die Leistung von APISIX bei etwa 120 % von Envoy, wenn man den Drucktest mit Envoy vergleicht, und je mehr Kerne vorhanden sind, desto größer ist der QPS-Unterschied.

Gesamtarchitektur

Wie aus dem folgenden Architekturdiagramm ersichtlich ist, dient APISIX Ingress als Einstiegspunkt für den gesamten Datenverkehr. Der gesamte Zugriffsverkehr gelangt über APISIX Ingress in das Upstream (Geschäftsdienste), unabhängig davon, ob er von Befehlszeilentools, Web, SaaS-Plattformen oder OpenAPI stammt. Da das Unternehmen über einen eigenen Authentifizierungsdienst verfügt, wird der forward-auth-Plugin von APISIX direkt für die externe Authentifizierung verwendet.

Auf der Gateway-Ebene gelangt der gesamte Datenverkehr über den Domainnamen ein, und der Datenverkehr durchläuft zunächst LVS, das an den Backend-APISIX-Knoten weitergeleitet wird. Anschließend verteilt APISIX den Datenverkehr gemäß den Routing-Regeln an den entsprechenden Pod. Auf LVS wurde der Standardport von APISIX Ingress von 9180 auf 80 geändert, um LVS direkt auf APISIX Ingress verweisen zu lassen, was die Weiterleitung des Datenverkehrs erleichtert.

Szenarien

Nachdem wir die Gesamtarchitektur verstanden haben, werden wir einige Szenarien teilen, die unser Unternehmen derzeit mit APISIX Ingress umsetzt.

Upload von übergroßen Dateien

Zunächst das Szenario des Uploads von großen Dateien, das in allgemeinen Unternehmen weniger verbreitet ist, aber in Unternehmen, die KI-Modelltraining durchführen, häufiger vorkommt. Dieses Szenario findet hauptsächlich im Modelltrainingssystem von Horizon Robotics statt, wo die von der Entwicklung gesammelten Daten über das Netzwerk in das System hochgeladen werden. Die Größe der Daten beträgt in der Regel mehrere hundert GB, und es kommt zu OOM, wenn die Menge der hochgeladenen Daten zu groß ist, ohne dass Parameter von APISIX angepasst werden.

Da die Standardgröße von client_body_buffer_size 1 MB beträgt, werden temporäre Dateien auf die Festplatte geschrieben, wenn der Puffer voll ist, was zu hoher Festplatten-IO führt.

Wenn das Verzeichnis, in das die temporären Dateien geschrieben werden, auf den gemeinsamen Speicher (/dev/shm) verweist, führt dies wiederum zu hohem APISIX-Cache.

Nach kontinuierlicher Fehlerbehebung stellten wir fest, dass der Grund darin lag, dass APISIX das Streaming-Upload nicht aktiviert hatte. Für dieses Szenario haben wir die APISIX-Version von 2.11 auf 2.13 aktualisiert und die APISIX-Parameter angepasst. Zuerst haben wir den Parameter proxy_request_buffering in der APISIX ConfigMap auf off gesetzt, um das Streaming-Upload zu aktivieren. Zweitens haben wir die wiederverwendbare Konfiguration aus dem CRD ApisixPluginConfig, das vom APISIX Ingress Controller bereitgestellt wird, extrahiert und client_max_body_size für die Routen, die dieses Szenario benötigen, dynamisch als namespace-Ebene-Konfiguration festgelegt.

Dienstaufrufe in Multi-Cloud-Umgebungen

Für Dienstaufrufe in Multi-Cloud-Umgebungen gelangt ein Teil des Geschäftsverkehrs zunächst zum lokalen IDC und dann über APISIX Ingress zum Pod. Einige Dienste im Pod greifen über den Domainnamen auf Dienste von AliCloud zu. Darüber hinaus gibt es auch Szenarien, in denen der Dienst andere Dienste aufruft, hauptsächlich für Multi-Cloud-Training. Benutzer nehmen den IDC als Einstiegspunkt und wählen den Cluster aus, um die Aufgabe an den entsprechenden Cloud-Cluster zu übermitteln.

Externe Authentifizierung mit forward-auth

Als wir APISIX Ingress erstmals verwendeten, unterstützte APISIX den forward-auth-Plugin nicht, daher haben wir ein benutzerdefiniertes Plugin basierend auf apisix-go-plugin-runner definiert. Dies führte jedoch zu einer zusätzlichen Ebene von gRPC-Aufrufen, was das Debugging erschwerte und die Protokollierung unsichtbar machte. Da APISIX zu Beginn dieses Jahres den forward-auth-Plugin unterstützte, haben wir das benutzerdefinierte Plugin durch das offizielle ersetzt, was eine Ebene von gRPC-Aufrufen reduziert und die Überwachung erleichtert.

Anwendungsüberwachung

In der Anwendungsüberwachung haben wir den APISIX Prometheus-Plugin global aktiviert und einige Anpassungen und Optimierungen für unser eigenes Geschäft vorgenommen, wie z.B. die Hinzufügung von Echtzeit-Concurrency, QPS, APISIX-Echtzeit-API-Erfolgsrate und APISIX-Echtzeit-Bandbreite für eine feinere Überwachung von APISIX.

Zusammenfassung

Wir verwenden derzeit den Apache APISIX Ingress Controller als Datenverkehrs-Gateway nur für einige unserer Geschäftsbereiche und werden andere Geschäftsbereiche live schalten, um der Community noch reichhaltigere Anwendungsszenarien zu bieten. Wenn Sie auch Ingress-Controller-Lösungen vergleichen, hoffen wir, dass dieser Artikel Ihnen einige Hinweise gibt. Immer mehr Benutzer verwenden Apache APISIX Ingress in Produktionsumgebungen, und wenn Sie auch APISIX Ingress verwenden, teilen Sie bitte Ihre Anwendungsfälle in der Community.