Wie treffe ich meine Wahl? API-Gateway vs. Ingress-Controller vs. Servicenetz

In nahezu jedem Webinar zu Ingress-Controllern und Service Meshes, das wir im Laufe des Jahres 2021 durchgeführt haben, hörten wir Variationen der Fragen „Wie unterscheidet sich dieses Tool von einem API-Gateway?“ oder „Brauche ich in Kubernetes sowohl ein API-Gateway als auch einen Ingress-Controller (oder ein Service Mesh)?“

Die Verwirrung ist aus zwei Gründen völlig verständlich:

• Ingress-Controller und Service-Meshes können viele API-Gateway-Anwendungsfälle erfüllen.
• Einige Anbieter positionieren ihr API-Gateway-Tool als Alternative zur Verwendung eines Ingress-Controllers oder Service Mesh – oder sie vereinen alle drei Funktionen in einem Tool.

In diesem Blog gehen wir darauf ein, wie sich diese Tools unterscheiden und welches für Kubernetes-spezifische API-Gateway-Anwendungsfälle verwendet werden sollte. Um tiefer in die Materie einzutauchen und Demos zu erhalten, sehen Sie sich das Webinar „API Gateway-Anwendungsfälle für Kubernetes“ an.

Definitionen

Im Kern sind API-Gateways, Ingress-Controller und Service-Meshes jeweils eine Art Proxy, der dafür ausgelegt ist, Datenverkehr in Ihre Umgebungen und um sie herum zu leiten.

Was ist ein API-Gateway?

Ein API-Gateway leitet API-Anfragen von einem Client an die entsprechenden Dienste weiter. Ein großes Missverständnis dieser einfachen Definition besteht jedoch in der Annahme, dass es sich bei einem API-Gateway um eine einzigartige Technologie handelt. Das ist es nicht. Vielmehr beschreibt „API-Gateway“ eine Reihe von Anwendungsfällen, die über verschiedene Arten von Proxys implementiert werden können – am häufigsten ein ADC bzw. Load Balancer und Reverse Proxy, zunehmend aber auch ein Ingress-Controller oder Service Mesh.

In der Branche besteht keine große Einigkeit darüber, welche Funktionen ein Tool unbedingt haben muss, um als API-Gateway dienen zu können. Normalerweise benötigen unsere Kunden die folgenden Fähigkeiten (gruppiert nach Anwendungsfall):

Anwendungsfälle für Resilienz

• A/B-Tests, Canary-Bereitstellungen und Blue-Green-Bereitstellungen
• Protokolltransformation (beispielsweise zwischen JSON und XML)
• Ratenbegrenzung
• Diensterkennung

Anwendungsfälle für das Verkehrsmanagement

• Methodenbasiertes Routing und Matching
• Anforderungs-/Antwortheader und Textkörpermanipulation
• Anforderungsrouting auf Ebene 7

Sicherheitsanwendungsfälle

• Durchsetzung des API-Schemas
• Clientauthentifizierung und -autorisierung
• Benutzerdefinierte Antworten
• Feinkörnige Zugriffskontrolle
• TLS-Terminierung

Fast alle dieser Anwendungsfälle werden häufig in Kubernetes verwendet. Protokolltransformationen sowie die Manipulation von Anforderungs-/Antwortheadern und -texten sind weniger verbreitet, da sie im Allgemeinen an ältere APIs gebunden sind, die für Kubernetes- und Microservices-Umgebungen nicht gut geeignet sind.

Weitere Informationen zu Anwendungsfällen für API-Gateways finden Sie in unserem Blog im Abschnitt „Bereitstellen von NGINX als API-Gateway, Teil 1“ .

Was ist ein Ingress-Controller?

Ein Ingress-Controller (auch Kubernetes Ingress Controller – kurz KIC – genannt) ist ein spezialisierter Layer-4- und Layer-7-Proxy, der Datenverkehr in Kubernetes hinein, zu den Diensten und wieder hinaus leitet (als Ingress-Egress- oder Nord-Süd-Datenverkehr bezeichnet). Neben der Verkehrsverwaltung können Ingress-Controller auch für Sichtbarkeit und Fehlerbehebung, Sicherheit und Identität sowie für alle API-Gateway-Anwendungsfälle außer den fortgeschrittensten verwendet werden.

Weitere Informationen dazu, wie Sie einen Ingress-Controller für mehr als nur die grundlegende Verkehrsverwaltung verwenden können, finden Sie im Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Identifizieren Sie Ihre Anforderungen in unserem Blog.

Was ist ein Service Mesh?

Ein Service Mesh verarbeitet den Datenverkehr zwischen Kubernetes-Diensten (als Service-zu-Service- oder Ost-West-Datenverkehr bezeichnet) und wird häufig verwendet, um eine Ende-zu-Ende- Verschlüsselung (E2EE) zu erreichen. Die Akzeptanz von Service Mesh ist gering, nimmt aber zu, da immer mehr Unternehmen erweiterte Bereitstellungen starten oder Anforderungen an E2EE haben. Ein Service Mesh kann als verteiltes (leichtgewichtiges) API-Gateway ganz in der Nähe der Apps verwendet werden, was auf der Datenebenenebene durch Service Mesh- Sidecars ermöglicht wird.

Weitere Informationen zum Service Mesh – und dazu, wann Sie dafür bereit sind – finden Sie in unserem Blog unter „So wählen Sie ein Service Mesh aus“ .

Verwenden Sie Kubernetes-native Tools für Kubernetes-Umgebungen

Wie wir von Mark Church in seiner NGINX Sprint 2.0- Keynote zu Kubernetes und der Zukunft der Anwendungsvernetzung hörten, „werden sich API-Gateways, Load Balancer und Service Meshes in Zukunft immer ähnlicher sehen und ähnliche Funktionen bieten“. Wir stimmen dieser Aussage voll und ganz zu und fügen hinzu, dass es vor allem darauf ankommt, das richtige Werkzeug für die jeweilige Arbeit auszuwählen, und zwar basierend darauf, wo (und wie) Sie es verwenden möchten. Schließlich dienen sowohl eine Machete als auch ein Buttermesser zum Schneiden, aber ersteres werden Sie wahrscheinlich nicht für Ihren Toast am Morgen verwenden.

Wie entscheiden Sie, welches Werkzeug das richtige für Sie ist? Wir machen es einfach: Wenn Sie API-Gateway-Funktionalität innerhalb von Kubernetes benötigen, ist es normalerweise am besten, ein Tool zu wählen, das mit nativen Kubernetes-Konfigurationstools wie YAML konfiguriert werden kann. Normalerweise ist das ein Ingress-Controller oder ein Service-Mesh. Aber wir hören Sie sagen: „Mein API-Gateway-Tool hat so viel mehr Funktionen als mein Ingress-Controller (oder Service Mesh) – verpasse ich da nicht etwas?“ NEIN! Mehr Funktionen bedeuten nicht automatisch ein besseres Tool, insbesondere bei Kubernetes, wo die Tool-Komplexität ein Killer sein kann.

Notiz: Kubernetes-native (nicht dasselbe wie Knative ) bezieht sich auf Tools, die für Kubernetes entwickelt und erstellt wurden. Normalerweise funktionieren sie mit der Kubernetes-CLI, können mit Helm installiert werden und lassen sich in Kubernetes-Funktionen integrieren.

Die meisten Kubernetes-Benutzer bevorzugen Tools, die sie Kubernetes-nativ konfigurieren können, da dadurch Änderungen an der Entwicklung oder der GitOps-Erfahrung vermieden werden. Ein YAML-freundliches Tool bietet drei große Vorteile:

• YAML ist für Kubernetes-Teams eine vertraute Sprache, daher ist die Lernkurve gering oder sogar nicht vorhanden, wenn Sie ein vorhandenes Kubernetes-Tool für die API-Gateway-Funktionalität verwenden. Auf diese Weise können Ihre Teams im Rahmen ihrer vorhandenen Fähigkeiten arbeiten, ohne die Konfiguration eines neuen Tools erlernen zu müssen, das sie möglicherweise nur gelegentlich verwenden.
• Sie können ein YAML-freundliches Tool auf die gleiche Weise automatisieren wie Ihre anderen Kubernetes-Tools. Alles, was sich nahtlos in Ihre Arbeitsabläufe einfügt, kommt bei Ihrem Team gut an – und erhöht die Wahrscheinlichkeit, dass es genutzt wird.
• Sie können Ihren Kubernetes-Toolstapel zur Verkehrsverwaltung verkleinern, indem Sie Ihren Ingress-Controller, Ihr Service Mesh oder beides verwenden. Schließlich ist jeder zusätzliche Hop wichtig und es gibt keinen Grund, unnötige Latenzen oder einzelne Ausfallpunkte hinzuzufügen. Und natürlich wirkt sich die Reduzierung der Anzahl der in Kubernetes eingesetzten Technologien auch positiv auf Ihr Budget und Ihre allgemeine Sicherheit aus.

Anwendungsfälle für das Nord-Süd-API-Gateway: Verwenden Sie einen Ingress-Controller

Ingress-Controller haben das Potenzial, viele Anwendungsfälle für API-Gateways zu ermöglichen. Zusätzlich zu den in den Definitionen beschriebenen Werten schätzen Organisationen unserer Meinung nach am meisten einen Ingress-Controller, der Folgendes implementieren kann:

• Auslagerung von Authentifizierung und Autorisierung
• Autorisierungsbasiertes Routing
• Routing und Matching auf Layer 7-Ebene (HTTP, HTTP/S, Header, Cookies, Methoden)
• Protokollkompatibilität (HTTP, HTTP/2, WebSocket, gRPC)
• Ratenbegrenzung

Beispielszenario: Routing auf Methodenebene

Sie möchten Matching und Routing auf Methodenebene implementieren und dabei den Ingress-Controller verwenden, um die POST- Methode in API-Anfragen abzulehnen.

Einige Angreifer suchen nach Schwachstellen in APIs, indem sie Anforderungstypen senden, die nicht einer API-Definition entsprechen. Dies können beispielsweise POST- Anforderungen an eine API sein, die so definiert ist, dass sie nur GET -Anforderungen akzeptiert. Web Application Firewalls (WAF) können diese Art von Angriffen nicht erkennen, da sie nur Anforderungszeichenfolgen und -texte auf Angriffe untersuchen. Daher empfiehlt es sich, auf der Ingress-Ebene ein API-Gateway zu verwenden, um fehlerhafte Anforderungen zu blockieren.

Angenommen, die neue API /coffee/{coffee-store}/brand wurde gerade zu Ihrem Cluster hinzugefügt. Der erste Schritt besteht darin, die API mithilfe des NGINX Ingress Controller verfügbar zu machen – indem Sie die API einfach zum Upstream -Feld hinzufügen.

API-Version: k8s.nginx.org/v1kind: VirtualServer
Metadaten:
Name: Café
Spezifikation:
Host: Café.Beispiel.com
TLS:
Geheimnis: Café-Geheimnis
Upstreams:
-Name: Tee
Dienst: Tee-SVC
Port: 80
-Name: Kaffee
Dienst: Kaffee-Dienst
Port: 80

Um die Übereinstimmung auf Methodenebene zu aktivieren, fügen Sie dem Routenfeld einen Pfad /coffee/{coffee-store}/brand hinzu und fügen zwei Bedingungen hinzu, die die Variable $request_method verwenden, um zwischen GET- und POST- Anfragen zu unterscheiden. Jeglicher Datenverkehr, der die HTTP- GET- Methode verwendet, wird automatisch an den Coffee- Dienst weitergeleitet. Der Datenverkehr mit der POST -Methode wird auf eine Fehlerseite mit der Meldung „Sie wurden abgelehnt!“ umgeleitet. Und schon haben Sie die neue API vor unerwünschtem POST- Verkehr geschützt.

Routen: - Pfad: /coffee/{coffee-store}/brand
Übereinstimmungen:
- Bedingungen:
- Variable: $request_method
Wert: POST
Aktion:
Rückgabe:
Code: 403
Typ: Text/Plain
Text: "Sie wurden abgelehnt!"
- Bedingungen:
- Variable: $request_method
Wert: GET
Aktion:
Passwort: Kaffee
- Pfad: /Tee
Aktion:
Passwort:Tee

Weitere Einzelheiten zur Verwendung des Routings auf Methodenebene und zum Abgleich mit Fehlerseiten finden Sie in der Dokumentation zum NGINX Ingress Controller . Ein sicherheitsrelevantes Beispiel für die Verwendung eines Ingress-Controllers für die API-Gateway-Funktionalität finden Sie in unserem Blog unter „Implementieren der OpenID Connect-Authentifizierung für Kubernetes mit Okta und NGINX Ingress Controller“ .

Anwendungsfälle für das Ost-West-API-Gateway: Verwenden eines Service Mesh

Für die meisten Anwendungsfälle von API-Gateways ist ein Service Mesh nicht erforderlich – oder zunächst nicht einmal hilfreich –, da die meisten Ihrer gewünschten Aufgaben auf der Ingress-Ebene erledigt werden können und sollten. Aber mit zunehmender Komplexität Ihrer Architektur ist es wahrscheinlicher, dass Sie durch die Verwendung eines Service Mesh einen größeren Nutzen erzielen. Die Anwendungsfälle, die wir am nützlichsten finden, beziehen sich auf E2EE und Verkehrsaufteilung – wie etwa A/B-Tests, Canary-Bereitstellungen und Blue-Green-Bereitstellungen.

Beispielszenario: Canary-Bereitstellung

Sie möchten eine Canary-Bereitstellung zwischen Diensten mit bedingtem Routing basierend auf HTTP/S-Kriterien einrichten.

Der Vorteil besteht darin, dass Sie API-Änderungen – etwa neue Funktionen oder Versionen – schrittweise einführen können, ohne den Großteil Ihres Produktionsverkehrs zu beeinträchtigen.

Derzeit leitet Ihr NGINX Ingress Controller den Datenverkehr zwischen zwei von NGINX Service Mesh verwalteten Diensten weiter: Coffee.frontdoor.svc und Tea.frontdoor.svc . Diese Dienste empfangen Datenverkehr vom NGINX Ingress Controller und leiten ihn an die entsprechenden App-Funktionen weiter, einschließlich Tea.cream1.svc . Sie beschließen, Tea.cream1.svc umzugestalten und nennen die neue Version Tea.cream2.svc . Sie möchten, dass Ihre Betatester Feedback zu den neuen Funktionen geben. Deshalb konfigurieren Sie eine Aufteilung des Canary-Verkehrs auf Grundlage des eindeutigen Sitzungscookies der Betatester. So stellen Sie sicher, dass Ihre regulären Benutzer nur Tea.cream1.svc erleben.

Mithilfe von NGINX Service Mesh erstellen Sie zunächst eine Verkehrsaufteilung zwischen allen Diensten, die von Tea.frontdoor.svc unterstützt werden, einschließlich Tea.cream1.svc und Tea.cream2.svc . Um das bedingte Routing zu aktivieren, erstellen Sie eine HTTPRouteGroup- Ressource (mit dem Namen „tea-hrg“ ) und verknüpfen sie mit der Verkehrsaufteilung. Das Ergebnis ist, dass nur Anfragen von Ihren Betabenutzern (Anfragen mit dem Sitzungscookie, das auf „version=beta“ gesetzt ist) von Tea.frontdoor.svc an Tea.cream2.svc weitergeleitet werden. Ihre regulären Benutzer nutzen hinter Tea.frontdoor.svc weiterhin nur Dienste der Version 1.

API-Version: split.smi-spec.io/v1alpha3kind: TrafficSplit
Metadaten:
Name: tea-svc
Spezifikation:
Dienst: tea.1
Backends:
- Dienst: tea.1
Gewicht: 0
- Service: Tee.2
Gewicht: 100
Übereinstimmungen:
- Art: HTTPRouteGroup
Name: tea-hrg

API-Version: specs.smi-spec.io/v1alpha3
Art: HTTPRouteGroup
Metadaten:
Name: tea-hrg
Namespace: Standard
Spezifikation:
Übereinstimmungen:
- Name: beta-session-cookie
Header:
- Cookie: „Version=Beta“

In diesem Beispiel wird Ihre Canary-Bereitstellung mit einer Aufteilung von 0:100 gestartet. Dies bedeutet, dass alle Ihre Betatester Tea.cream2.svc erleben. Sie können jedoch natürlich mit jedem anderen Verhältnis beginnen, das Ihrer Betateststrategie entspricht. Sobald Ihr Betatest abgeschlossen ist, können Sie eine einfache Canary-Bereitstellung (ohne Cookie-Routing) verwenden, um die Widerstandsfähigkeit von Tea.cream2.svc zu testen.

Weitere Informationen zur Verkehrsaufteilung mit NGINX Service Mesh finden Sie in unserer Dokumentation . Die obige Konfiguration zur Verkehrsaufteilung ist selbstreferenziell, da der Root-Dienst auch als Backend-Dienst aufgeführt ist. Diese Konfiguration wird derzeit von der Service Mesh Interface-Spezifikation ( SMI-Spec ) nicht unterstützt. Die Spezifikation befindet sich derzeit jedoch in der Alpha-Phase und kann sich noch ändern.

Wann (und wie) Sie ein API-Gateway-Tool für Kubernetes-Apps verwenden

Obwohl die meisten API-Gateway-Anwendungsfälle für Kubernetes von einem Ingress-Controller oder Service Mesh angesprochen werden können (und sollten), gibt es einige spezielle Situationen, in denen sich ein API-Gateway-Tool – beispielsweise NGINX Plus – eignet.

Geschäftliche Anforderungen

Obwohl mehrere Teams oder Projekte einen Satz von Ingress-Controllern gemeinsam nutzen können oder Ingress-Controller für einzelne Umgebungen spezialisiert werden können, gibt es Gründe, warum Sie sich für die Bereitstellung eines dedizierten API-Gateways in Kubernetes entscheiden könnten, anstatt den vorhandenen Ingress-Controller zu nutzen. Die Verwendung sowohl eines Ingress-Controllers als auch eines API-Gateways innerhalb von Kubernetes kann Unternehmen die nötige Flexibilität bieten, um Geschäftsanforderungen zu erfüllen. Einige Szenarien umfassen:

• Ihr API-Gateway-Team ist mit Kubernetes nicht vertraut und verwendet kein YAML. Wenn sie beispielsweise mit der NGINX-Konfiguration vertraut sind, verringert sich der Aufwand und die Lernkurve wird kürzer, wenn sie NGINX Plus als API-Gateway in Kubernetes bereitstellen.
• Ihr Platform-Ops-Team möchte den Ingress-Controller lieber ausschließlich der Verwaltung des App-Verkehrs widmen.
• Sie haben einen API-Gateway-Anwendungsfall, der nur für einen der Dienste in Ihrem Cluster gilt. Anstatt einen Ingress-Controller zu verwenden, um eine Richtlinie auf Ihren gesamten Nord-Süd-Verkehr anzuwenden, können Sie ein API-Gateway bereitstellen, um die Richtlinie nur dort anzuwenden, wo sie benötigt wird.

Migrieren von APIs in Kubernetes-Umgebungen

Wenn Sie vorhandene APIs in Kubernetes-Umgebungen migrieren, können Sie diese APIs in einem API-Gateway-Tool veröffentlichen, das außerhalb von Kubernetes bereitgestellt wird. In diesem Szenario wird der API-Verkehr normalerweise über einen externen Load Balancer (zur Lastverteilung zwischen Clustern) geleitet, dann zu einem Load Balancer, der als API-Gateway dient, und schließlich zum Ingress-Controller in Ihrem Kubernetes-Cluster.

Unterstützung von SOAP-APIs in Kubernetes

Die meisten modernen APIs werden zwar mit REST erstellt – zum Teil, weil RESTful- oder gRPC-Dienste und -APIs die Vorteile der Kubernetes-Plattform voll ausschöpfen können. Dennoch gibt es möglicherweise noch einige SOAP-APIs, die nicht neu konzipiert wurden. Obwohl SOAP-APIs für Kubernetes nicht empfohlen werden, da sie nicht für Microservices optimiert sind, müssen Sie möglicherweise eine SOAP-API in Kubernetes bereitstellen, bis sie neu strukturiert werden kann. Wahrscheinlich muss die API mit REST-basierten API-Clients kommunizieren. In diesem Fall benötigen Sie eine Möglichkeit zur Übersetzung zwischen den SOAP- und REST-Protokollen. Obwohl Sie diese Funktion mit einem Ingress-Controller ausführen können, empfehlen wir dies nicht, da es extrem ressourcenintensiv ist. Stattdessen empfehlen wir die Bereitstellung eines API-Gateway-Tools als Proxy pro Pod oder pro Dienst zur Übersetzung zwischen SOAP und REST.

API-Verkehrsmanagement innerhalb und außerhalb von Kubernetes

Eine relativ kleine Anzahl unserer Kunden ist an der Verwaltung von APIs innerhalb und außerhalb von Kubernetes-Umgebungen interessiert. Wenn eine API-Verwaltungsstrategie eine höhere Priorität hat als die Auswahl nativer Kubernetes-Tools, ist ein in Kubernetes bereitgestelltes „Kubernetes-freundliches“ API-Gateway (das in eine API-Verwaltungslösung integriert werden kann) möglicherweise die richtige Wahl.

Notiz: Im Gegensatz zu Kubernetes-nativen Tools wurden Kubernetes-freundliche Tools (manchmal auch Kubernetes-accommodative genannt) nicht für Kubernetes entwickelt und können nicht mithilfe von Kubernetes-Konfigurationen verwaltet werden. Sie sind jedoch flexibel und leicht, sodass sie in Kubernetes ausgeführt werden können, ohne dass es zu erheblicher Latenz kommt oder umfangreiche Workarounds erforderlich sind.

Erste Schritte mit NGINX

NGINX bietet Optionen für alle drei Arten von Bereitstellungsszenarien.

Kubernetes-native Tools:

• NGINX Ingress Controller – NGINX Plus-basierter Ingress Controller für Kubernetes, der erweiterte Verkehrskontrolle und -gestaltung, Überwachung und Sichtbarkeit sowie Authentifizierung und Single Sign-On (SSO) übernimmt.
• NGINX Service Mesh – Leichtes, schlüsselfertiges und entwicklerfreundliches Service Mesh mit NGINX Plus als Enterprise-Sidecar.

Fordern Sie zunächst Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an und laden Sie das stets kostenlose NGINX Service Mesh herunter .

Für ein Kubernetes-freundliches API-Gateway innerhalb oder außerhalb Ihrer Kubernetes-Umgebungen:

• NGINX Plus – Der All-in-One- Load Balancer, Reverse-Proxy, Webserver und API-Gateway mit Funktionen auf Unternehmensniveau wie Hochverfügbarkeit, aktiven Integritätsprüfungen, DNS-Systemerkennung, Sitzungspersistenz und einer RESTful-API. Integriert mit NGINX Controller [jetzt F5 NGINX Management Suite ] für eine vollständige API-Lebenszykluslösung.

Um mehr über die Verwendung von NGINX Plus als API-Gateway zu erfahren, fordern Sie Ihre kostenlose 30-Tage-Testversion an und lesen Sie den Artikel „Bereitstellen von NGINX als API-Gateway“ .