Warum ist der APISIX Ingress Controller besser als der NGINX Ingress Controller?

Ingress stellt Dienste in Kubernetes bereit, wobei das Routing des Datenverkehrs durch Regeln gesteuert wird, die auf der Ingress-Ressource konfiguriert sind. Um einen Ingress zu erfüllen, benötigen Sie auch einen Ingress-Controller.

In diesem Artikel werden wir zwei beliebte Ingress-Controller vergleichen, um den Lesern Einblicke in die Auswahl von Ingress-Controllern zu geben.

• Ingress-NGINX ist ein Ingress-Controller, der von der Kubernetes-Community implementiert wird und in der Community weit verbreitet ist.
• APISIX Ingress Controller verwendet Apache APISIX, ein Open-Source-Projekt unter der ASF (Apache Software Foundation), als seine Datenebene.

Ingress NGINX vs. APISIX Ingress

Feature-Vergleich

Die folgende Tabelle vergleicht die grundlegenden Funktionen von Ingress NGINX und APISIX Ingress, einschließlich Protokolle, Upstream-Prüfungen/Resilienzen, Lastausgleichsstrategien, Authentifizierung, Kubernetes-Integration usw. Die Tabelle wurde von learnk8s.io extrahiert.

Unterschiede

Wir können aus der folgenden Abbildung ersehen, dass APISIX Ingress mehr integrierte Funktionen und Features bietet als Ingress NGINX, einschließlich Protokollunterstützung, Healthchecks und Circuit Breaker, Authentifizierung, Kubernetes-Integration usw.

Service Discovery

In der Microservices-Architektur wird die Anwendung in viele Microservices unterteilt. Immer wenn ein Microservice ausfällt oder ein Dienst hoch- oder herunterskaliert wird, muss der Aufrufer so schnell wie möglich benachrichtigt werden, um Aufrufausfälle zu vermeiden. Daher sind der Dienstregistrierungs- und Dienstermittlungsmechanismus in der Microservice-Architektur von entscheidender Bedeutung, die normalerweise von der Dienstregistrierung verwaltet wird.

Protokollunterstützung

Während beide Ingress-Controller das HTTP/HTTPS-Protokoll unterstützen, unterstützt APISIX mehr Protokolle. Es unterstützt TLS zur Verschlüsselung von TCP-Datenverkehr. Es unterstützt auch MQTT, Dubbo und kafka für das Proxying.

Upstream-Prüfungen/Resilienz

Healthchecks

Wenn ein Knoten ausfällt oder migriert, ist es unvermeidlich, dass der Knoten nicht verfügbar ist. Wenn eine große Anzahl von Anfragen auf diese nicht verfügbaren Knoten zugreift, führt dies zu Datenverlust und Geschäftsunterbrechungen. Daher ist es notwendig, Healthchecks an den Knoten durchzuführen, indem Prüfungen verwendet werden, und Anfragen an gesunde Knoten zu leiten, um Datenverluste zu reduzieren.

Die Healthcheck-Funktionalität wird in Ingress NGINX noch nicht unterstützt, aber APISIX Ingress bietet diese Funktionalität:

• Aktive Prüfung: Verwendet Prüfungen, um sicherzustellen, dass die Pods im Backend gesund sind. Wenn N aufeinanderfolgende Prüfungen an einen Knoten fehlschlagen, wird der Knoten als ungesund markiert. Der Lastausgleich ignoriert die ungesunden Knoten, sodass sie keine Anfragen erhalten können. Die Aktivierung aktiver Healthchecks kann effektiv ungesunde Pods deaktivieren, um Datenverluste zu vermeiden.
• Passive Prüfung: Die passive Healthcheck benötigt keine zusätzlichen Prüfungen. Jede an den Knoten gesendete Anfrage fungiert als Prüfung. Wenn N aufeinanderfolgende Anfragen an einen gesunden Knoten fehlschlagen, wird der Knoten als ungesund markiert. Da der Knotenstatus im Voraus nicht erkannt werden kann, kann es zu einer gewissen Anzahl fehlgeschlagener Anfragen kommen. Diese Situation ist bei Rolling Updates relativ häufig, und wir können Service-Degradierungen verwenden, um die Anzahl fehlgeschlagener Anfragen zu vermeiden.

Beispiel für die Konfiguration von Healthchecks für den httpbin-Dienst in APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixUpstream
metadata:
  name: httpbin
spec:
  healthCheck:
    passive:
      unhealthy:
        httpCodes:
          - 500
        httpFailures: 3
    active:
      type: http
      httpPath: /healthz
      healthy:
        successes: 3
        interval: 2s
        httpCodes:
          - 200

Circuit Breaker

Das Gateway ist ein Einstiegspunkt für Anfragen; es initiiert Aufrufe an den Backend-Dienst. Wenn der Datenverkehr seinen Höhepunkt erreicht und die Last hoch ist, kann der Backend-Dienst aufgrund von Timeouts oder Ausnahmen fehlschlagen. Wenn der Fehler auftritt, können Anfragen nicht auf dem Gateway gestapelt werden. Es muss schnell zurückkehren, was einen Abbruch auf dem Gateway erfordert.

Ähnlich wie die Healthcheck-Funktion wird die Funktion des Dienstabbruchs in Ingress NGINX nicht unterstützt. In APISIX Ingress hilft das api-breaker-Plugin bei der Implementierung.

Beispielkonfiguration des Circuit Breakers in APISIX Ingress:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /status/*
   backends:
   - serviceName: httpbin
     servicePort: 80
   plugins:
   - name: api-breaker
     enable: true
     config:
       break_response_code: 502
       unhealthy:
         http_statuses:
         - 505
         failures: 2
       healthy:
         http_statuses:
         - 200
         successes: 2

Unterstützung für mehr Plugins und Authentifizierungsmethoden

Ingress NGINX verwendet hauptsächlich Annotations und ConfigMap für die Konfiguration, und die unterstützten Plugins sind relativ begrenzt. Wenn Sie JWT, HAMC oder andere Authentifizierungsmethoden verwenden möchten, müssen Sie diese selbst integrieren.

APISIX Ingress unterstützt 80+ Plugins in APISIX nativ, die mehrere Authentifizierungsmethoden wie JWT, HAMC, wolf-rbac usw. unterstützen. Diese Plugins bieten eine Vielzahl von Funktionen, die die meisten Anwendungsfälle abdecken.

Beispiel für HMAC-Authentifizierung auf einer APISIX-Route:

apiVersion: apisix.apache.org/v2
kind: ApisixConsumer
metadata:
  name: hmac-value
spec:
  authParameter:
    hmacAuth:
      value:
        access_key: papa
        secret_key: fatpa
        algorithm: "hmac-sha256"
        clock_skew: 0
---

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
 name: httpbin-route
spec:
 http:
 - name: rule1
   match:
     hosts:
     - httpbin.org
     paths:
       - /ip
   backends:
   - serviceName: httpbin
     servicePort: 80
   authentication:
     enable: true
     type: hmacAuth

Erweiterbarkeit von Ingress NGINX und APISIX Ingress

Wenn die grundlegenden Funktionen des Ingress-Controllers die Anforderungen von Unternehmensbenutzern nicht erfüllen können, kann er nur durch Erweiterung angepasst werden. Als Nächstes erklären wir, wie Ingress NGINX und APISIX Ingress ihre Funktionen erweitern.

Wie Ingress NGINX seine Funktionen erweitert

Ingress NGINX kann nur durch das Einbetten von Lua-Programmen erweitert werden.

Ingress NGINX Plugin-Entwicklung Beispiel:

1. Schreiben Sie das Lua-Programm example-plugin
2. Installieren Sie das Plugin in /etc/nginx/lua/plugins/<Ihr Plugin-Name> $\rightarrow$ /etc/nginx/lua/plugins/example-plugin im ingress-nginx-Pod
3. Aktivieren Sie das example-plugin in ConfigMap und verweisen Sie auf dieses ConfigMap-Objekt bei der Installation von Ingress NGINX

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  plugins: "example-plugin"

Wie APISIX Ingress seine Funktionen erweitert

APISIX Ingress bietet verschiedene Methoden zur Erweiterung von Funktionen, und Unternehmensbenutzer können die Methode frei nach ihren eigenen Anforderungen wählen. APISIX unterstützt:

• Plugin-Entwicklung über Lua: einfach und mit fast keinem Leistungsverlust
• Entwicklung über Plugin-Runner: Programmiersprachen wie JAVA/Python/Go werden für die Entwicklung unterstützt, sodass Benutzer ihre Plugins anpassen können, ohne neue Sprachen zu lernen
• Plugins über WASM: Jede Sprache, die den Bau von WASM unterstützt, kann für die Plugin-Entwicklung verwendet werden

Darüber hinaus können Sie direkt Lua-Code über das Serverless-Plugin schreiben, um schnell geschäftliche Anforderungen zu erfüllen.

Warum unterstützt APISIX Ingress CustomResourceDefinition (CRD)?

Derzeit unterstützt APISIX Ingress drei deklarative Konfigurationen: Ingress, CRD und Gateway API. Wir werden hier hauptsächlich Ingress und CRD vergleichen. Und wir werden die Gateway API später erklären.

Ingress ist besser für Unternehmensbenutzer geeignet, die von Ingress NGINX migrieren, da die Migrationskosten niedrig sind. Seine Nachteile sind jedoch ebenfalls offensichtlich, wie schwache semantische Fähigkeiten, keine Standardvorgaben usw. Und Ingress kann nur über Annotations erweitert werden, aber Annotations können komplexe Szenarien nicht unterstützen. Im Vergleich dazu hat CRD die folgenden Vorteile:

• Einfacher zu verwenden, da es besser mit den Design-Semantiken der Datenebene übereinstimmt
• Wiederverwendbarkeit von Konfigurationen, um Redundanz zu reduzieren
• Verbesserte Funktionalität und Erweiterbarkeit
• Die Datenebene von APISIX hat eine aktive Community, mit schnellen Updates und Veröffentlichungen, und CRD kann die Fähigkeiten der Datenebene leicht unterstützen

Schmerzpunkt von Ingress NGINX: Hot Reloading wird nicht unterstützt

Probleme durch statische Konfiguration

Ingress NGINX wird hauptsächlich auf der Grundlage von NGINX-Konfigurationsdateien implementiert. Obwohl NGINX und Lua verwendet werden, um Funktionserweiterungen zu erreichen, löst dies das Problem der statischen Konfigurationsdateien nur teilweise. Es zeigt Unzulänglichkeiten in seinen Routing- und Neuladefähigkeiten. Zum Beispiel muss die NGINX-Konfiguration neu geladen werden, wenn eine Regel hinzugefügt oder geändert wird. Mit immer mehr Routing-Regeln und Zertifikaten dauert der Ladevorgang länger, von einigen Sekunden bis zu mehr als zehn Sekunden. Jedes Neuladen von NGINX setzt den Lastausgleichszustand zurück, was sich negativ auf den Online-Datenverkehr auswirkt, kurze Unterbrechungen verursacht, die Antwortzeit erhöht und die Qualität des Lastausgleichs verringert.

Situationen, die ein NGINX-Neuladen auslösen

• Erstellen einer neuen Ingress-Ressource
• Hinzufügen eines TLS-Abschnitts zu einer bestehenden Ingress
• Ändern von Ingress-Annotations, die die Upstream-Konfiguration beeinflussen können (z.B. Lastausgleichs-Annotations müssen nicht neu geladen werden)
• Hinzufügen oder Löschen eines Pfads in Ingress
• Löschen von Ingress-, Service- oder Secret-Ressourcen
• Aktualisieren von Secret

Die oben aufgeführten Situationen decken die meisten Anwendungsfälle des Ingress-Controllers ab. In einer Cluster-Umgebung, in der Anwendungen häufig bereitgestellt werden, werden Operationen (Erstellen, Aktualisieren, Löschen usw.) von Ressourcen wie Ingress und Secret kontinuierlich ausgelöst. Dies führt zu einem starken Anstieg der Anzahl der NGINX-Neuladungen, was sich erheblich auf die Produktionsumgebung auswirkt.

Die Architektur von Ingress NGINX bestimmt, dass zuerst die NGINX-Konfiguration generiert und neu geladen werden muss, um die Konfigurationsaktualisierung abzuschließen. Das Problem des Neuladens kann nicht gelöst werden, ohne die Architektur anzupassen. Um dieses Problem zu lösen, verlässt sich APISIX Ingress bei der Implementierung des Routings nicht mehr auf die NGINX-Konfiguration und wechselt zu einer reinen Speicherarchitektur. Dynamisches Routing wird durch Hot Reloading realisiert, und NGINX muss nicht mehr neu gestartet werden.

Gateway API

Vorteile der Kubernetes Gateway API

Die Kubernetes Gateway API ist funktionaler als Ingress und wurde entwickelt, um das Kubernetes-Service-Netzwerk durch eine ausdrucksstarke, erweiterbare und rollenorientierte Schnittstelle zu entwickeln, die von vielen Anbietern implementiert wird und breite Branchenunterstützung genießt. Die Gateway API hat die folgenden Eigenschaften:

• Rollenorientiert: Gateway besteht aus API-Ressourcen. Unterschiedliche API-Ressourcen repräsentieren unterschiedliche Rollen für die Verwendung und Konfiguration von Kubernetes-Netzwerkressourcen

• Starke Ausdruckskraft: Die Gateway API unterstützt Kernfunktionen, einschließlich Header-basiertem Matching, Traffic-Gewichtung und anderen Fähigkeiten, die in Ingress nur durch benutzerdefinierte, nicht standardisierte Annotations möglich waren

• Erweiterbar: Die Gateway API ermöglicht es, verschiedene Ressourcen auf verschiedenen API-Ebenen zu verknüpfen. Dies ermöglicht eine granulare Anpassung innerhalb der API-Struktur

Unterstützungsstatus der Gateway API

Die Kubernetes Gateway API ist ein Standard für die Erweiterung des Kubernetes-Service-Meshs. Ihre Gateway-Ressource kann als Kubernetes-API verwendet werden, um den Lebenszyklus des Gateways zu verwalten, was sehr leistungsfähig ist. Viele Ingress-Controller unterstützen sie aktiv, darunter Istio, Kong, Traefik usw. Leider plant Ingress NGXIN noch nicht, die Gateway API zu unterstützen (Gateway API Implementierungsstatus), während APISIX Ingress bereits die meisten Funktionen der Gateway API unterstützt: einschließlich HTTPRoute, TCPRoute, TLSRoute, UDPRoute usw.

Zusammenfassung

Nach einem gründlichen Vergleich von APISIX Ingress und Ingress NGINX können wir schließen, dass beide Open-Source-Software hervorragend sind und die wesentlichen Funktionen der beiden ähnlich sind. In der Microservice-Architektur zeigt APISIX Ingress jedoch mehr Vorteile bei der Unterstützung von Service-Governance und Service Discovery durch die Bereitstellung von Healthchecks und Circuit Breaking.

Ingress NGINX zeichnet sich durch seine Einfachheit und Benutzerfreundlichkeit aus, hat jedoch einige offensichtliche Nachteile, wie Schwierigkeiten bei der Funktionserweiterung. APISIX Ingress, der später hinzukam, löste den Schmerzpunkt des Hot Reloadings von NGINX und bot bessere Erweiterbarkeiten und Funktionalitäten. Zum Beispiel unterstützt die Gateway API und CRD die Fähigkeiten des Ingress-Controllers in Bezug auf die Projektentwicklung.

Kurz gesagt, wenn Sie einen Ingress-Controller mit reichhaltigeren Funktionen und besserer Erweiterbarkeit auswählen möchten, wird APISIX Ingress dringend empfohlen. Wenn Sie neu im Bereich der Ingress-Controller sind und nicht viele funktionale Anforderungen haben, ist Ingress NGINX aufgrund seiner Einfachheit ebenfalls eine gute Wahl.