Warum Jiakaobaodian den APISIX Ingress Controller wählt

Mit der Verbreitung von Kubernetes (kurz K8s) haben wir neben dem offiziellen Standard-NGINX Ingress Controller mehr Optionen zur Auswahl, und der Apache APISIX Ingress Controller ist ebenfalls zu einer beliebten Wahl für viele Unternehmen geworden. Immer mehr Unternehmen ersetzen schrittweise ihren Ingress Controller durch den APISIX Ingress Controller.

Hintergrund

Die Wuhan Mucang Technology Co., Ltd. wurde 2011 gegründet und ihre Hauptprodukte sind Dutzende von Autoanwendungen wie Jiakaobaodian. Seit ihrer Gründung vor mehr als 10 Jahren hat das Unternehmen den Technologietrend verfolgt und 2019 begonnen, Cloud-native zu nutzen, und verschiedene Projekte im Unternehmen haben Kubernetes eingeführt.

Aber zu dieser Zeit, als K8s gerade aufkam, gab es nur wenige Optionen für den Traffic-Eingang. Daher haben wir fast 4 Jahre lang den standardmäßigen Ingress Controller – NGINX Ingress Controller – verwendet. Während dieser Zeit wurde jedoch immer deutlicher, dass der NGINX Ingress Controller unsere Anforderungen nicht mehr erfüllen konnte, was uns zwang, eine neue Wahl zu treffen. Nach einem Vergleich der gängigen Ingress Controller entschieden wir uns, Apache APISIX als Einstiegsgateway des Unternehmens zu verwenden.

Das Problem mit dem NGINX Ingress Controller

Die Dienste im Unternehmen verwenden das HTTP-Protokoll und das TCP-Protokoll, und nur die Betriebs- und Wartungsingenieure wissen genau, wie der TCP-Proxy über den NGINX Ingress Controller konfiguriert wird. Die personellen Ressourcen für den Betrieb und die Wartung sind jedoch begrenzt. Es wäre am besten, wenn wir einige der grundlegenden NGINX-Operationen und -Konfigurationen an das Entwicklungsteam übergeben könnten, um die Betriebskosten zu senken.

Abgesehen davon sind wir auch auf folgende Probleme gestoßen:

Einige Konfigurationsänderungen erfordern ein Neuladen;
Der TCP-Proxy hat hohe Nutzungskosten und kann nicht alle Arten von Traffic-Szenarien abdecken;
Routing- oder Traffic-Operationen können nur durch annotations definiert werden, und wir können Konfigurationen nicht semantisch definieren und wiederverwenden;
Umleitungen, Unterbrechungen, Anforderungsübertragungen und andere Operationen werden durch annotations implementiert;
Fehlende Management-Plattform, und das Betriebspersonal muss über YAML operieren, was fehleranfällig ist;
Schlechte Portierbarkeit;
Nicht förderlich für die Integration in Container-Plattformen.

Aus diesen Gründen haben wir beschlossen, unseren bisherigen Ingress Controller durch einen neuen zu ersetzen.

Warum APISIX Ingress Controller

Wir haben Apache APISIX und andere Ingress Controller untersucht und sie in Bezug auf Leistung, Benutzerfreundlichkeit, Erweiterbarkeit und Plattformintegration verglichen und schließlich den APISIX Ingress Controller als K8s-Traffic-Eingangsgateway ausgewählt, und zwar aus folgenden Gründen.

Gute Erweiterbarkeit;
Unterstützung für Konfigurations-Hot-Loading;
Hohe Leistung;
Viele Plugins;
Unterstützung von CRD für die Integration mit der selbst entwickelten Container-Plattform.

Gesamtarchitektur

Nachdem dies gesagt ist, werfen wir einen Blick auf die gesamte Gateway-Architektur. In einem tatsächlichen Geschäftsszenario leiten Benutzer den Traffic zunächst über SLB (Server Load Balancer) weiter, und wenn der Traffic in K8s eintritt, wird jeder Dienst über den APISIX-Cluster aufgerufen. Wir implementieren auch viele gängige Funktionen (Canary-Release, Flusskontrolle, API-Unterbrechung, Traffic-Sicherheitskontrolle, Anforderungs-/Antwort-Traffic-Kontrolle usw.) auf der Gateway-Seite, um die Verwaltung der Dienste zu vereinheitlichen, die Komplexität des Geschäfts zu verringern und Kosten zu sparen.

Architekturdiagramm

Bereitstellungsmethode

Unser Geschäft ist auf verschiedenen Cloud-Plattformen (Huawei Cloud, Tencent Cloud, Alibaba Cloud) bereitgestellt, und wir können unser Geschäft schnell online bringen, indem wir Helm Chart verwenden, das vom APISIX Ingress Controller unterstützt wird. Wenn wir den APISIX Ingress Controller verwenden und Funktionen finden, die verbessert werden können, reichen wir auch PRs ein, um der Community zu helfen, die Funktionen zu aktualisieren und zu iterieren. Im tatsächlichen Bereitstellungsprozess haben wir einige Konfigurationen entsprechend unseren Geschäftsanforderungen angepasst, wie z.B.:

Erstellen von NameSpace über K8s, Bereitstellen von APISIX und APISIX Ingress Controller in verschiedenen NameSpaces und Trennen des Traffics nach Produktlinien und Dienstwichtigkeit;
Optimierung der Linux-TCP-Kernelparameter in APISIX initContainer;
Da wir den Traffic nach Produktlinien und Dienstwichtigkeit trennen müssen, müssen die ClassName-Informationen von K8s konfiguriert werden.

Durch die Trennung des Traffics nach verschiedenen Produktlinien und Wichtigkeit können Sie den Verlust durch Softwarefehler minimieren.

Integration mit selbst entwickelten Container-Plattformen mit CRD

Der APISIX Ingress Controller unterstützt derzeit viele CRD-Ressourcen, sodass wir CRD-Ressourcen verwenden können, um den APISIX Ingress Controller mit unserer eigenen Container-Plattform zu integrieren. Da APISIX jedoch keinen Java-Client bereitstellt, müssen wir das von K8s bereitgestellte Code-Generierungstool verwenden, um das Modell zu generieren, und CustomObjectApi verwenden, um die CRD zu verwalten. Die ApisixRoute-Objekte sind mit Container-Plattformanwendungen verknüpft und mit Kernobjekten strukturiert, sodass sowohl Betriebspersonal als auch Projektmanager in der Container-Plattform operieren können.

Anwendungsszenarien

Authentifizierung

Bevor wir Apache APISIX verwendeten, haben wir die Authentifizierung auf der Grundlage des Istio-Gateways implementiert, und nach der Migration zu Apache APISIX haben wir uns entschieden, das forward-auth-Plugin zu verwenden, das die Authentifizierungs- und Autorisierungslogik geschickt auf einen externen Auth-Dienst verlagert. Die Anfrage des Benutzers wird über das Gateway an den Auth-Dienst weitergeleitet, und wenn der Auth-Dienst mit einem nicht-20x-Status antwortet, wird die ursprüngliche Anfrage blockiert und das Ergebnis ersetzt. Auf diese Weise ist es möglich, einen benutzerdefinierten Fehlerbericht zurückzugeben oder den Benutzer bei einem Authentifizierungsfehler auf die Authentifizierungsseite umzuleiten.

Wenn ein Client eine Anfrage an eine Anwendung sendet, wird sie zunächst vom forward-auth-Plugin von APISIX verarbeitet, und die Anfrage wird über forward-auth an einen externen Authentifizierungsdienst weitergeleitet, und das Ergebnis wird schließlich an das APISIX-Gateway zurückgegeben. Wenn die Authentifizierung erfolgreich ist, kann der Client den Dienst normal anfordern. Wenn die Authentifizierung fehlschlägt, wird ein Fehlercode zurückgegeben.

Flusskontrolle

Aufgrund der Geschäftsmerkmale des Unternehmens gibt es jedes Jahr fünf oder sechs Monate mit Spitzentraffic. Sobald es zu viele Anfragen gibt, müssen wir manuell die Kapazität erweitern, aber aufgrund der Rückstauung von Anfragen kann der Dienst nach der Erweiterung möglicherweise nicht starten, was zu einem Lawinenausfall der gesamten Verbindung führen kann, sodass wir den Fluss und die Geschwindigkeit des Clusters begrenzen müssen.

Daher verwenden wir die Plugins limit-conn, limit-req und limit-count von APISIX, um Anfragen zu begrenzen und Lawinenausfälle zu verhindern. Es ist einfacher, den Fluss und die Geschwindigkeit durch die Änderung von Plugins zu begrenzen, und aufgrund des APISIX-Hot-Loading-Mechanismus ist es nicht erforderlich, die Plugins neu zu starten, wenn sie konfiguriert werden, sodass sie sofort wirksam werden. Durch die Kontrolle des Traffics kann es auch einige böswillige Angriffe stoppen und die Systemsicherheit schützen. Wir haben auch HPA (Horizontal Pod Autoscaler) in der K8s-Plattform implementiert, das automatisch hoch- und herunterskaliert, sobald die Traffic-Menge zu groß oder zu klein ist, mit APISIX-Fluss- und Ratenbegrenzungs-Plugins, um massive Ausfälle zu verhindern.

Beobachtbarkeit

In Bezug auf die Beobachtbarkeit überwachen wir derzeit den plattformübergreifenden Traffic über SkyWalking. Das APISIX SkyWalking-Plugin ermöglicht eine direkte Schnittstelle zur bestehenden SkyWalking-Plattform, und die SkyWalking-UI macht es einfach, die Leistungsverbrauchsknoten der Verbindung zu sehen. Da sich die Überwachungspunkte auf der Gateway-Seite befinden und somit näher am Benutzer liegen, ist es einfacher, die zeitaufwändigen Punkte zu überprüfen.

Mit dem kafka-logger-Plugin können die von APISIX generierten Zugriffs- und Fehlerprotokolle direkt in den Apache Kafka-Cluster geschrieben werden. Mit diesem Vorteil kann der APISIX-Cluster zustandslos und horizontal skaliert werden, ohne dass eine Formatierung von Festplatten, eine Protokollrotation oder andere Operationen erforderlich sind. Wenn die Protokolle lokal gespeichert werden, müssen wir einige zusätzliche Operationen durchführen und können keine schnelle Skalierung erreichen. Durch das Senden der Protokolle an den Apache Kafka-Cluster können wir die Protokolle auch in Echtzeit analysieren und das System basierend auf den Analyseergebnissen verbessern und optimieren.

Fazit

Da der APISIX Ingress Controller gerade erst eingeführt wurde, gibt es noch nicht so viele Anwendungsszenarien. Wir werden weiterhin tiefer in die Anwendungsszenarien eintauchen und der Community weitere Nutzungsbeispiele bringen.

Immer mehr Teams verwenden den Apache APISIX Ingress Controller in der Produktionsumgebung. Wenn Sie auch den APISIX Ingress Controller verwenden, ermutigen wir Sie, Ihre Anwendungsfälle in der Community zu teilen.