Wie treffe ich die richtige Wahl? API-Gateway vs. Ingress-Controller vs. Service-Mesh

Jenn GileLeiter Produktmarketing, NGINX

In fast jedem Webinar über Ingress-Controller und Service Meshes, das wir im Laufe des Jahres 2021 veranstaltet haben, wurden uns Varianten der folgenden Fragen gestellt: „Wie unterscheidet sich dieses Tool von einem API-Gateway?“ oder „Benötige 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 Anwendungsfälle von API-Gateways abdecken.
• Einige Anbieter positionieren ihr API-Gateway-Tool als Alternative zur Verwendung eines Ingress-Controllers oder Service Meshs – oder sie vereinen alle drei Funktionen in einem einzigen Tool.

In diesem Blogbeitrag erläutern wir, wie sich diese Tools unterscheiden und welches sich für Kubernetes-spezifische API-Gateway-Anwendungsfälle eignet. Für einen tieferen Einblick einschließlich Demos 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, die dafür konzipiert ist, Datenverkehr in Ihre Umgebungen hinein und innerhalb dieser weiterzuleiten.

Was ist ein API-Gateway?

Ein API-Gateway leitet API-Anfragen eines Clients an die entsprechenden Dienste weiter. Ein großes Missverständnis bei dieser einfachen Definition ist jedoch die Annahme, dass ein API-Gateway eine eigenständige Technologie sei. Das ist nicht der Fall. Vielmehr bezeichnet „API-Gateway“ eine Reihe von Anwendungsfällen, die sich mithilfe verschiedener Proxy-Typen umsetzen lassen – meist mit einem ADC oder Load Balancer und Reverse Proxy, zunehmend aber auch mit einem Ingress-Controller oder Service Mesh.

In der Branche herrscht wenig Einigkeit darüber, welche Funktionen ein Tool unbedingt bieten muss, um als API-Gateway eingesetzt werden zu können. In der Regel erwarten Kunden die folgenden Funktionen (nach Anwendungsfall gruppiert):

Anwendungsfälle für Ausfallsicherheit

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

Anwendungsfälle für das Traffic-Management

• Methodenbasiertes Routing und Matching
• Manipulation von Anfrage-/Antwort-Headern und -Textkörpern
• Anfragen-Routing auf Layer 7

Sicherheitsanwendungsfälle

• Durchsetzung des API-Schemas
• Client-Authentifizierung und -Autorisierung
• Benutzerdefinierte Antworten
• Feingranulare Zugriffskontrolle
• TLS-Terminierung

Fast alle diese Anwendungsfälle sind in Kubernetes weit verbreitet. Protokolltransformationen sowie die Manipulation von Headern und Bodys von Anfragen und Antworten kommen seltener zum Einsatz, da sie in der Regel mit Legacy-APIs verknüpft sind, die sich für Kubernetes- und Microservices-Umgebungen nicht besonders gut eignen.

Weitere Informationen zu den Anwendungsfällen von API-Gateways finden Sie in NGINX als API-Gateway bereitstellen, Teil 1 in unserem Blog.

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 den Datenverkehr in Kubernetes hinein, zu den Services und wieder hinaus leitet (auch als Ingress-Egress- oder Nord-Süd-Datenverkehr bezeichnet). Neben der Datenverkehrssteuerung können Ingress-Controller auch für Transparenz und Fehlerbehebung, Sicherheit und Identitätsmanagement sowie für nahezu alle API-Gateway-Anwendungsfälle mit Ausnahme der komplexesten eingesetzt werden.

Erfahren Sie mehr darüber, wie Sie einen Ingress-Controller für mehr als nur die grundlegende Datenverkehrssteuerung einsetzen können, in unserem Blogbeitrag „Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen“.

Was ist ein Service Mesh?

Ein Service Mesh verarbeitet den Datenverkehr zwischen Kubernetes-Services (auch als Service-to-Service- oder Ost-West-Datenverkehr bezeichnet) und wird häufig eingesetzt, um eine Ende-zu-Ende-Verschlüsselung (E2EE) zu ermöglichen. Service Meshes sind noch wenig verbreitet, werden jedoch zunehmend eingesetzt, da immer mehr Unternehmen komplexe Bereitstellungen umsetzen oder E2EE benötigen. Ein Service Mesh kann als verteiltes (leichtgewichtiges) API-Gateway in unmittelbarer Nähe zu den Anwendungen eingesetzt werden. Dies wird auf der Datenebene durch Sidecars des Service Mesh ermöglicht.

Erfahren Sie mehr über Service Meshes – und darüber, wann Sie für eines bereit sind – in unserem Blogbeitrag „So wählen Sie ein Service Mesh aus“.

Kubernetes-native Tools für Kubernetes-Umgebungen verwenden

Wie wir von Mark Church in seiner NGINX-Sprint-2.0-Keynote zum Thema Kubernetes und die Zukunft der Anwendungsvernetzung gehört haben, „werden sich API-Gateways, Load Balancer und Service Meshes immer ähnlicher sehen und vergleichbare Funktionen bieten“. Dieser Aussage stimmen wir voll und ganz zu und möchten ergänzen, dass es darauf ankommt, je nachdem, wo (und wie) es eingesetzt werden soll, das richtige Werkzeug für die jeweilige Aufgabe auszuwählen. Schließlich dienen sowohl eine Machete als auch ein Buttermesser zum Schneiden, aber für Ihren morgendlichen Toast werden Sie wahrscheinlich nicht zur Machete greifen.

Wie entscheiden Sie also, welches Tool das richtige für Sie ist? Wir machen es Ihnen einfach: Wenn Sie API-Gateway-Funktionen innerhalb von Kubernetes benötigen, sollten Sie in der Regel ein Tool wählen, das sich mit nativen Kubernetes-Konfigurationswerkzeugen wie YAML konfigurieren lässt. Üblicherweise handelt es sich dabei um einen Ingress-Controller oder ein Service Mesh. Aber vielleicht fragen Sie sich: „Mein API-Gateway-Tool bietet so viel mehr Funktionen als mein Ingress-Controller (oder Service Mesh) – entgeht mir da nicht etwas?“ Nein! Mehr Funktionen bedeuten nicht automatisch ein besseres Tool, insbesondere innerhalb von Kubernetes, wo die Komplexität eines Tools zum Verhängnis werden kann.

Hinweis: Kubernetes-nativ (nicht zu verwechseln mit Knative) bezeichnet Tools, die speziell für Kubernetes konzipiert und entwickelt wurden. In der Regel 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 auf Kubernetes-native Weise konfigurieren können, da so Änderungen an der Entwicklungs- oder GitOps-Erfahrung vermieden werden. Ein YAML-freundliches Tool bietet drei wesentliche Vorteile:

• YAML ist Kubernetes-Teams vertraut, sodass die Einarbeitung nur gering oder sogar überhaupt nicht erforderlich ist, wenn Sie ein vorhandenes Kubernetes-Tool für API-Gateway-Funktionen verwenden. So können Ihre Teams ihre vorhandenen Kenntnisse nutzen, ohne lernen zu müssen, wie ein neues Tool konfiguriert wird, das sie möglicherweise nur gelegentlich verwenden.
• Ein YAML-freundliches Tool lässt sich genauso automatisieren wie Ihre anderen Kubernetes-Tools. Alles, was sich nahtlos in Ihre Workflows einfügt, wird bei Ihrem Team gut ankommen – und damit steigt die Wahrscheinlichkeit, dass es auch genutzt wird.
• Sie können die Anzahl Ihrer Tools für das Kubernetes-Traffic-Management reduzieren, indem Sie Ihren Ingress-Controller, Ihr Service Mesh oder beides verwenden. Schließlich zählt jeder zusätzliche Hop, und es gibt keinen Grund, unnötige Latenzen oder Single Points of Failure hinzuzufügen. Und natürlich wirkt es sich auch positiv auf Ihr Budget und die allgemeine Sicherheit aus, wenn Sie die Anzahl der in Kubernetes eingesetzten Technologien reduzieren.

Anwendungsfälle für ein North-South-API-Gateway: Verwenden Sie einen Ingress-Controller

Ingress-Controller können zahlreiche Anwendungsfälle für API-Gateways ermöglichen. Zusätzlich zu den unter Definitionen beschriebenen Funktionen schätzen Unternehmen unserer Erfahrung nach vor allem einen Ingress-Controller, der Folgendes implementieren kann:

• Auslagerung von Authentifizierung und Autorisierung
• Autorisierungsbasiertes Routing
• Routing und Abgleich 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 den Abgleich und das 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 Anfragetypen senden, die nicht der API-Definition entsprechen – beispielsweise POST-Anfragen an eine API, die laut Definition nur GET-Anfragen akzeptiert. Web Application Firewalls (WAFs) können solche Angriffe nicht erkennen, da sie lediglich Anfragezeichenfolgen und -inhalte auf Angriffe untersuchen. Daher empfiehlt es sich, auf der Ingress-Ebene ein API-Gateway einzusetzen, um unzulässige Anfragen zu blockieren.

Nehmen wir als Beispiel an, dass die neue API /coffee/{coffee-store}/brand gerade zu Ihrem Cluster hinzugefügt wurde. Im ersten Schritt stellen Sie die API über den NGINX Ingress Controller bereit, indem Sie sie einfach zum Feld upstreams hinzufügen.

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80

Um den Abgleich auf Methodenebene zu aktivieren, fügen Sie dem Feld routes den Pfad /coffee/{coffee-store}/brand sowie zwei Bedingungen hinzu, die anhand der Variable $request_method zwischen GET- und POST-Anfragen unterscheiden. Sämtlicher Datenverkehr, der die HTTP-Methode GET verwendet, wird automatisch an den Coffee-Dienst weitergeleitet. Datenverkehr, der die POST-Methode verwendet, wird auf eine Fehlerseite mit der Meldung „Sie wurden abgewiesen!“ umgeleitet. Und schon haben Sie die neue API vor unerwünschtem POST-Datenverkehr geschützt.

routes: - path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "Sie wurden abgewiesen!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea

Weitere Informationen zur Verwendung von Routing und Abgleichen auf Methodenebene mit Fehlerseiten finden Sie in der Dokumentation zum NGINX Ingress Controller. Ein sicherheitsbezogenes Beispiel für die Verwendung eines Ingress Controllers als API-Gateway finden Sie in unserem Blogbeitrag „Implementierung der OpenID-Connect-Authentifizierung für Kubernetes mit Okta und dem NGINX Ingress Controller“.

Anwendungsfälle für Ost-West-API-Gateways: Verwenden Sie ein Service Mesh

Für die meisten API-Gateway-Anwendungsfälle ist ein Service Mesh nicht erforderlich – und anfangs nicht einmal hilfreich –, da sich die meisten gewünschten Funktionen auf der Ingress-Ebene umsetzen lassen und auch dort umgesetzt werden sollten. Mit zunehmender Komplexität Ihrer Architektur steigt jedoch die Wahrscheinlichkeit, dass Ihnen der Einsatz eines Service Mesh einen Mehrwert bietet. Als besonders vorteilhaft erachten wir Anwendungsfälle im Zusammenhang mit E2EE und Traffic-Splitting – etwa A/B-Tests, Canary-Deployments und Blue-Green-Deployments.

Beispielszenario: Canary-Bereitstellung

Sie möchten ein Canary-Deployment zwischen Diensten mit bedingtem Routing auf Grundlage von HTTP/S-Kriterien einrichten.

Der Vorteil besteht darin, dass Sie API-Änderungen – wie neue Funktionen oder Versionen – schrittweise einführen können, ohne den Großteil Ihres Produktionsdatenverkehrs 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 Anwendungsfunktionen weiter, darunter Tea.cream1.svc. Sie beschließen, Tea.cream1.svc zu überarbeiten und die neue Version Tea.cream2.svc zu nennen. Sie möchten, dass Ihre Betatester Feedback zu den neuen Funktionen geben. Daher konfigurieren Sie eine Canary-Aufteilung des Datenverkehrs auf Grundlage des eindeutigen Sitzungscookies der Betatester und stellen so sicher, dass Ihre regulären Benutzer ausschließlich Tea.cream1.svc verwenden.

Mit NGINX Service Mesh erstellen Sie zunächst eine Datenverkehrsaufteilung zwischen allen Diensten, die von Tea.frontdoor.svc bereitgestellt 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 Datenverkehrsaufteilung. Dadurch werden nur Anfragen Ihrer Beta-Benutzer (Anfragen, bei denen das Sitzungscookie auf version=beta gesetzt ist) von Tea.frontdoor.svc an Tea.cream2.svc weitergeleitet. Ihre regulären Benutzer greifen weiterhin ausschließlich auf Dienste der Version 1 hinter Tea.frontdoor.svc zu.

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"

In diesem Beispiel beginnt Ihr Canary-Deployment mit einer 0‑100-Aufteilung. Das bedeutet, dass alle Ihre Betatester Tea.cream2.svc verwenden. Natürlich können Sie auch mit einem beliebigen Verhältnis beginnen, das zu Ihrer Betateststrategie passt. Sobald Ihr Betatest abgeschlossen ist, können Sie mit einem einfachen Canary-Deployment (ohne Cookie-Routing) die Ausfallsicherheit von Tea.cream2.svc testen.

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

Wann (und wie) Sie ein API-Gateway-Tool für Kubernetes-Anwendungen einsetzen sollten

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

Geschäftliche Anforderungen

Mehrere Teams oder Projekte können sich zwar eine Gruppe von Ingress-Controllern teilen, und Ingress-Controller können auch für einzelne Umgebungen spezialisiert werden. Dennoch kann es Gründe geben, innerhalb von Kubernetes ein dediziertes API-Gateway bereitzustellen, anstatt den vorhandenen Ingress-Controller zu nutzen. Der gemeinsame Einsatz eines Ingress-Controllers und eines API-Gateways innerhalb von Kubernetes bietet Unternehmen die nötige Flexibilität, um geschäftliche Anforderungen zu erfüllen. Mögliche Szenarien sind:

• Ihr API-Gateway-Team ist mit Kubernetes nicht vertraut und verwendet kein YAML. Wenn es beispielsweise mit der NGINX-Konfiguration vertraut ist, verringert die Bereitstellung von NGINX Plus als API-Gateway in Kubernetes Reibungsverluste und erleichtert die Einarbeitung.
• Ihr Platform-Ops-Team möchte den Ingress-Controller ausschließlich für die Verwaltung des Anwendungsdatenverkehrs einsetzen.
• Sie haben einen API-Gateway-Anwendungsfall, der nur für einen der Dienste in Ihrem Cluster gilt. Anstatt mit einem Ingress-Controller eine Richtlinie auf Ihren gesamten Nord-Süd-Datenverkehr anzuwenden, können Sie ein API-Gateway bereitstellen, das die Richtlinie nur dort anwendet, wo sie benötigt wird.

APIs in Kubernetes-Umgebungen migrieren

Bei der Migration bestehender APIs in Kubernetes-Umgebungen können Sie diese APIs über ein API-Gateway-Tool veröffentlichen, das außerhalb von Kubernetes bereitgestellt ist. In diesem Szenario wird der API-Datenverkehr in der Regel zunächst über einen externen Load Balancer (für den Lastenausgleich zwischen Clustern), dann an einen als API-Gateway konfigurierten Load Balancer und schließlich an den Ingress-Controller innerhalb Ihres Kubernetes-Clusters weitergeleitet.

Unterstützung von SOAP-APIs in Kubernetes

Obwohl die meisten modernen APIs mit REST erstellt werden – unter anderem, weil RESTful- oder gRPC-Dienste und -APIs die Kubernetes-Plattform voll ausschöpfen können –, verfügen Sie möglicherweise noch über einige SOAP-APIs, deren Architektur noch nicht überarbeitet wurde. SOAP-APIs werden für Kubernetes nicht empfohlen, da sie nicht für Microservices optimiert sind. Dennoch kann es erforderlich sein, eine SOAP-API vorübergehend in Kubernetes bereitzustellen, bis ihre Architektur überarbeitet werden kann. Wahrscheinlich muss die API mit REST-basierten API-Clients kommunizieren. In diesem Fall benötigen Sie eine Möglichkeit, zwischen den SOAP- und REST-Protokollen zu übersetzen. Diese Funktionalität lässt sich zwar mit einem Ingress-Controller umsetzen, wir raten jedoch davon ab, da dies äußerst ressourcenintensiv ist. Stattdessen empfehlen wir, ein API-Gateway-Tool als Proxy pro Pod oder pro Dienst bereitzustellen, um zwischen SOAP und REST zu übersetzen.

API-Traffic-Management innerhalb und außerhalb von Kubernetes

Eine relativ kleine Zahl unserer Kunden ist daran interessiert, APIs sowohl innerhalb als auch außerhalb von Kubernetes-Umgebungen zu verwalten. Wenn eine API-Management-Strategie eine höhere Priorität hat als die Auswahl Kubernetes-nativer Tools, könnte ein in Kubernetes bereitgestelltes „Kubernetes-freundliches“ API-Gateway, das sich in eine API-Management-Lösung integrieren lässt, die richtige Wahl sein.

Hinweis: Im Gegensatz zu Kubernetes-nativen Tools wurden Kubernetes-freundliche Tools (manchmal auch als Kubernetes-kompatibel bezeichnet) nicht für Kubernetes entwickelt und können nicht über Kubernetes-Konfigurationen verwaltet werden. Sie sind jedoch flexibel und schlank, sodass sie in Kubernetes eingesetzt werden können, ohne die Latenz erheblich zu erhöhen oder umfangreiche Workarounds zu erfordern.

Erste Schritte mit NGINX

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

Kubernetes-native Tools:

• NGINX Ingress Controller – auf NGINX Plus basierender Ingress-Controller für Kubernetes, der erweiterte Funktionen zur Datenverkehrssteuerung und -formung, Überwachung und Transparenz sowie Authentifizierung und Single Sign-on (SSO) bietet.
• NGINX Service Mesh – Eine schlanke, sofort einsatzbereite und entwicklerfreundliche Service-Mesh-Lösung mit NGINX Plus als Sidecar für Unternehmen.

Fordern Sie zum Einstieg Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an und laden Sie die dauerhaft 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 Enterprise-Niveau wie Hochverfügbarkeit, aktiven Zustandsprüfungen, DNS-Systemerkennung, Sitzungspersistenz und einer RESTful API. Lässt sich in NGINX Controller integrieren [jetzt F5 NGINX Management Suite] und bietet so eine Komplettlösung für den gesamten API-Lebenszyklus.

Wenn Sie mehr über den Einsatz von NGINX Plus als API-Gateway erfahren möchten, fordern Sie Ihre kostenlose 30-Tage-Testversion an und lesen Sie NGINX als API-Gateway bereitstellen.

Über den Autor

Jenn GileLeiter Produktmarketing, NGINX

Weitere Blogbeiträge von Jenn Gile