Warum AISpeech Apache APISIX anstelle von NGINX als k8s Ingress Controller wählt

Vorwort

Hallo zusammen, ich bin Jin Wei von AISpeech, einem High-Tech-Unternehmen, das sich auf Computer-Spracherkennung und -Analyse spezialisiert hat, und ich bin hier, um über die Integration von Apache APISIX mit K8s anstelle von nativen Ingress zu sprechen.

Zum Zeitpunkt des Verfassens dieses Textes wird Apache APISIX bereits in unserer Produktionsumgebung eingesetzt und übernimmt einen Teil des Geschäftsverkehrs. Wir migrieren schrittweise den nativen Ingress-Verkehr, wie in der folgenden Abbildung dargestellt.

Tatsächlich registriert der APISIX-ingress-controller die Pod-IP im Upstream-Knoten, sodass der Geschäftsverkehr den Pod direkt erreichen und den kube-DNS umgehen kann. Auf dieser Grundlage können Sie bestimmte Lastausgleichsrichtlinien über Plugins implementieren. Daher verlassen wir uns einerseits auf diese dynamische Routing-Fähigkeit von Apache APISIX für die Verkehrsverteilung. Andererseits fügen wir einige benutzerdefinierte Plugins hinzu, um Geschäftsanforderungen zu erfüllen.

Aus dem obigen Diagramm sieht der APISIX-ingress-controller redundant im Vergleich zum nativen Ingress aus. In diesem Artikel werden wir kurz erklären, warum wir den nativen Ingress aufgegeben und unseren eigenen Ingress-Controller auf der Grundlage von Apache APISIX entwickelt haben.

Was ist Ingress?

Kurz gesagt, Ingress ist eine Möglichkeit für Kubernetes, externen Verkehr zu handhaben.

Welches Problem löst Ingress?

Da die Dienste innerhalb eines Kubernetes-Clusters virtuelle Netzwerke sind, benötigt externer Verkehr mindestens eine öffentliche IP und einen korrekt zugeordneten Port, um auf die internen Dienste innerhalb des Clusters zuzugreifen.

Kubernetes bietet verschiedene Möglichkeiten (NodePort, LoadBalancer, Ingress, …), um Schnittstellen für den Zugriff auf interne Kubernetes-Dienste bereitzustellen. Im Vergleich dazu ist Ingress definitiv eine wirtschaftlichere Möglichkeit, einen Reverse-Proxy bereitzustellen, indem eine begrenzte Anzahl öffentlicher IPs freigegeben wird.

Wenn wir von Reverse-Proxies sprechen, könnten wir auch direkt einen NGINX aufbauen, um dies zu tun, aber es ist deutlich schwieriger, den Status der sich ständig ändernden Dienste in Kubernetes mit NGINX zu synchronisieren.

Die gute Nachricht ist, dass Kubernetes offiziell einen NGINX-Ingress-Controller bereitstellt und pflegt, um den Reverse-Proxy zu unterstützen. Mit diesem NGINX-Ingress-Controller können wir den gesamten Verkehr, der auf Kubernetes zugreifen möchte, korrekt an die Backend-Dienste weiterleiten.

Probleme mit dem nativen Kubernetes Ingress Controller

Der NGINX-Ingress-Controller hilft uns, die Status-Synchronisation zwischen dem Kubernetes-Cluster und NGINX aufrechtzuerhalten und bietet grundlegende Reverse-Proxy-Fähigkeiten. Warum also bauen wir unseren eigenen Ingress? Wir erwarten mehr vom Ingress-Controller, um weitere Geschäftsanforderungen zu erfüllen.

Nach der Verwendung des nativen Kubernetes-Ingress-Controllers haben wir festgestellt, dass die folgenden Probleme besonders hervorstechen:

1. Neuladen-Problem

   Der native Kubernetes-Ingress ist so konzipiert, dass YAML-Konfigurationsdateien an den Ingress-Controller übergeben werden, in NGINX-Konfigurationsdateien umgewandelt werden und dann ein Neuladen ausgelöst wird, um die Konfiguration wirksam zu machen.

   Dies ist inakzeptabel, insbesondere wenn der Verkehr langfristige Verbindungen verwendet, was zu Unfällen führen kann.

   Im Gegensatz dazu unterstützt Apache APISIX das Hot-Reloading von Konfigurationen, sodass Sie Routen jederzeit definieren und ändern können, ohne ein NGINX-Neuladen auszulösen.

2. Schreiben von Skripten und Füllen von Parametern in Annotationen

   Der native Ingress-Controller unterstützt Skriptausschnitte, die durch Annotationen in der YAML-Datei definiert werden, was sich wie eine vorübergehende Lösung zur Unterstützung erweiterter Funktionen anfühlt und ehrlich gesagt wirklich schwer zu verwalten ist. Die große Anzahl von Annotationsskripten verursacht Probleme für das DevOps-Personal.

   In Apache APISIX können wir Logik über Plugin-Code schreiben, um eine einfache Konfigurationsschnittstelle bereitzustellen, die die Konfigurationswartung erleichtert und die Störung des DevOps-Personals durch Skripte vermeidet.

3. Fehlende Unterstützung für zustandsbehafteten Lastausgleich

   Erweiterte Lastausgleichsrichtlinien werden nicht unterstützt, wie z.B. „Sitzungsbeibehaltung“. Kubernetes ist ein betriebsorientiertes, containerisiertes Anwendungsmanagementsystem, was möglicherweise damit zu tun hat, dass Kubernetes einen zustandslosen Bereitstellungsansatz fördert, sodass Kubernetes diese widersprüchlichen Lastausgleichsrichtlinien in naher Zukunft offiziell nicht unterstützen wird. Tatsächlich hat Google bereits versucht, diese Probleme mit seiner Service-Mesh-Lösung (Istio) zu lösen. Die Architektur von Istio ist perfekt, aber auf Kosten der Leistung, was möglicherweise mit Mixer v2 gelöst werden kann.

   Da Kubernetes Skalierung unterstützt, können wir auch Apache APISIX erweitern, um unsere erweiterten Lastausgleichsanforderungen zu erfüllen, da Apache APISIX nicht nur „Sitzungsbeibehaltung“ und andere Lastausgleichsrichtlinien nativ unterstützt, sondern auch die Fähigkeit hat, die Balancer-Phase zu skalieren.

4. Dynamische Gewichtung

   Geschäftsdienste müssen oft den Verkehr prozentual steuern, was in Kubernetes zu einem Problem wird.

   Obwohl Kubernetes ab Version 1.8 IPVS (IP Virtual Server) unterstützt, sind weder die Startparameter von „kube-proxy“ noch die Annotationen von „kube-route“ so benutzerfreundlich wie Apache APISIX, das intern Route, Service, Consumer, Upstream, Plugin und andere Hauptobjekte abstrahiert. Das Anpassen der Gewichtung solcher Operationen wird natürlich unterstützt, einfach durch Ändern der „Node-Gewichtung“ unter „Upstream“.

5. Unflexible Erweiterungsfähigkeiten

   Obwohl Ingress ursprünglich entwickelt wurde, um externen Verkehr zu handhaben, gibt es nicht weniger Anforderungen an externen Verkehr als an internen Verkehr.

   Service-Level-Canary-Release, Circuit Breaking, Flusskontrolle, Authentifizierung, Verkehrskontrolle und andere Anforderungen werden häufiger auf Ingress implementiert.

   Apache APISIX bietet Plugin-Unterstützung für Skalierbarkeit, und zusätzlich zu den offiziellen Plugins können Sie benutzerdefinierte Plugins erstellen, um Ihre eigenen Anforderungen zu erfüllen.

   Es gibt auch einige Konfigurationsprobleme, die durch ConfigMap und Namespaces verursacht werden, die mit unserer Nutzungsweise zusammenhängen und nicht allgemeingültig sind, daher werde ich hier nicht näher darauf eingehen.

Apache APISIX Ingress Controller

Aufgrund der leistungsstarken Routing- und Skalierungsfähigkeiten von Apache APISIX kann die Verwendung von Apache APISIX als Implementierung von Ingress die oben genannten Schmerzpunkte leicht lösen und der Community eine zusätzliche Option für einen Ingress-Controller bieten. Das Zeitdiagramm ist wie folgt:

Um den Apache APISIX-Ingress-Controller zu implementieren, müssen wir zwei grundlegende Probleme lösen: eines ist die Synchronisation zwischen dem Kubernetes-Cluster und dem Apache APISIX-Status; das andere ist die Definition der Objekte in Apache APISIX in Kubernetes (CRD).

Um Apache APISIX schnell zu integrieren und seine Vorteile zu nutzen, haben wir das Apache APISIX-Ingress-Controller-Projekt erstellt (jeder ist willkommen, teilzunehmen), das derzeit das erste grundlegende Problem löst: die Synchronisation von Kubernetes-Pod-Informationen mit Apache APISIX-Upstream, während eine primäre Sicherung implementiert wird, um seine eigenen Hochverfügbarkeitsprobleme zu lösen.

Da Kubernetes YAML verwendet, um den Clusterstatus deklarativ zu definieren, müssen wir CRD (Custom Resource Definitions) für die Objekte (Route/Service/Upstream/Plugin) in Apache APISIX definieren, um sie in Kubernetes zu integrieren.

Um die Migration bestehender Kubernetes-Ingress-Benutzer zu erleichtern, werden wir versuchen, mit den bestehenden Ingress-Konfigurationselementen kompatibel zu sein.

Diese Funktionen werden das Ziel unserer nächsten Bemühungen sein, und wir freuen uns über Ihre Teilnahme.