Gateway API und Edge Routing in Kubernetes verbinden

TL;DR

Die Kubernetes Gateway API trennt Zuständigkeiten zwischen Infrastruktur, Plattform und Anwendung deutlich besser als klassische Ingress-Ressourcen. Für öffentliches Routing reicht die Modellierung im Cluster jedoch nicht immer aus. Eine Edge-Plattform wie die ayedo Edge Cloud verbindet Kubernetes-Routing mit Anycast, Loadbalancing, TLS, Schutzfunktionen und Backend-Failover.

Einleitung

Öffentliche Routing-Regeln sollten nicht automatisch dort enden, wo ein Kubernetes-Cluster beginnt. Ein häufiger Architekturfehler besteht darin, Ingress oder Gateway API als vollständige Definition des externen Datenpfads zu betrachten. Diese Ressourcen beschreiben vor allem, wie Traffic innerhalb beziehungsweise bis zu einem Gateway verarbeitet wird. DNS, Anycast, DDoS-Schutz, TLS-Terminierung, Backend-Abschirmung und Failover liegen jedoch auf einer vorgelagerten Ebene. Die zentrale Frage lautet deshalb nicht, ob Kubernetes Gateway API oder Edge Routing eingesetzt wird. Entscheidend ist, wie beide Modelle mit klaren Verantwortungsgrenzen zusammenspielen und welche Routing-Regeln an welcher Stelle technisch und betrieblich wirksam werden.

1. Ingress und Gateway API modellieren Routing unterschiedlich

Das klassische Ingress-Modell bündelt externe HTTP- und HTTPS-Regeln in einer vergleichsweise kompakten Ressource. Hosts und Pfade verweisen auf Services; ein Ingress Controller setzt diese Vorgaben in eine konkrete Proxy- oder Loadbalancer-Konfiguration um. Das Modell ist etabliert, bildet Zuständigkeiten aber nur begrenzt ab. TLS, Controller-spezifische Annotationen und erweiterte Routing-Funktionen landen häufig in derselben Konfiguration.

Die Kubernetes Gateway API führt dafür explizitere Rollen ein. Ein Gateway beschreibt einen Eintrittspunkt und seine Listener, während HTTPRoute Regeln für Hosts, Pfade und Backends definiert. Über GatewayClass und Referenzen lassen sich Infrastruktur- und Anwendungsebene sauberer trennen. Das ist insbesondere relevant, wenn mehrere Teams Routing-Regeln verwalten, ohne den öffentlichen Netzwerkzugang selbst kontrollieren zu müssen.

Für Edge Routing entsteht dadurch ein zweistufiges Modell: Die Edge nimmt den öffentlichen Traffic an und verteilt ihn auf erreichbare Backends. Kubernetes Gateway API beschreibt anschließend, welche Anwendung innerhalb dieser Backend-Struktur zuständig ist.

2. Der öffentliche Datenpfad endet nicht am Gateway

Ein Kubernetes Gateway ist ein Routing- und Policy-Punkt im Clusterkontext. Der öffentliche Eingang kann jedoch davor liegen. Anycast DNS und Anycast-basiertes Layer-4- und Layer-7-Loadbalancing bestimmen, wie Anfragen die Edge erreichen und auf geeignete Backends verteilt werden. Diese Ebene kann unabhängig davon bestehen, ob das Backend ein ayedo Managed Kubernetes Cluster, ein eigener Cluster oder eine Kubernetes-Umgebung bei einem anderen Provider ist.

Diese Trennung verhindert, dass jeder Cluster direkt als öffentlich exponierter Endpunkt behandelt werden muss. TLS kann an der Edge terminiert werden; Backend Cloaking reduziert die Sichtbarkeit interner Endpunkte. Health Checks und Failover beziehen sich auf die Erreichbarkeit der Backends, während HTTPRoute die fachliche Weiterleitung innerhalb des Zielsystems beschreibt.

Wichtig ist die Semantik der Regeln: Ein Hostname kann an der Edge als Routing- und Schutzgrenze dienen und im Cluster erneut durch HTTP Routing ausgewertet werden. Das ist keine zwangsläufige Doppelkonfiguration, sondern eine bewusste Aufteilung von Netzwerk- und Anwendungsebene.

3. Verantwortlichkeiten zwischen Edge und Kubernetes abgrenzen

Die Gateway API schafft eine bessere Delegation, ersetzt aber keine Architekturentscheidung über den externen Traffic. Infrastrukturverantwortliche definieren typischerweise Gateway- beziehungsweise Listener-relevante Vorgaben, während Anwendungsteams HTTPRoute-Ressourcen für ihre Services verwalten. An der Edge müssen parallel Fragen zu DNS, IP-Adressierung, TLS, Schutz und Backend-Erreichbarkeit beantwortet werden.

Eine belastbare Integration braucht deshalb ein klares Ownership-Modell. Wer darf einen öffentlichen Host registrieren? Wer ändert ein Backend? Wie werden Zertifikate und Failover geprüft? Welche Regeln gelten, wenn eine HTTPRoute im Cluster vorhanden ist, der Host an der Edge aber nicht freigeschaltet wurde? Ohne diese Antworten entstehen Konfigurationen, die syntaktisch gültig, aber operativ wirkungslos sind.

Die ayedo Edge Cloud ist in diesem Modell keine reine Erweiterung von Managed Kubernetes. Ihre Kubernetes-native Integration kann öffentliche Routing-Anforderungen mit Clustern unterschiedlicher Betriebsmodelle verbinden. Die Edge bleibt für Eingang, Schutz und Verteilung verantwortlich; Kubernetes bleibt der Ort für workloadnahe Routing- und Servicebeziehungen.

4. Routing-Modelle beeinflussen Security und Betrieb

Ingress und Gateway API unterscheiden sich nicht nur in ihrer Ausdrucksstärke, sondern auch in der Steuerbarkeit des Betriebs. Ingress-Konfigurationen hängen oft stark von Controller-spezifischen Erweiterungen ab. Das kann Migrationen erschweren und Sicherheitsprüfungen unübersichtlich machen. Gateway API standardisiert zentrale Konzepte wie Listener, Routen und Referenzen stärker und unterstützt damit klarere Plattformgrenzen.

Für die Edge ist zusätzlich entscheidend, welche Prüfungen vor dem Cluster stattfinden. Eine Web Application Firewall kann HTTP- und HTTPS-Anfragen an der Edge bewerten, während DDoS Protection und Scrubbing volumetrische oder protokollbezogene Belastungen vom Backend fernhalten. Proxy Protocol kann Informationen über die ursprüngliche Verbindung an nachgelagerte Systeme weitergeben, sofern die Backend-Kette dies unterstützt.

Betrieblich entsteht ein zentraler Vorteil durch die Entkopplung: Änderungen an HTTPRoute müssen nicht zwangsläufig die öffentliche IP- oder DNS-Struktur verändern. Umgekehrt können Edge-Routing, TLS oder Failover angepasst werden, ohne jede Anwendungskonfiguration im Cluster neu zu modellieren. Das reduziert Kopplung, verlangt aber konsequentes Monitoring beider Ebenen.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt dieselbe Anwendung in zwei Kubernetes-Clustern. An der Edge wird ein öffentlicher Hostname über Anycast DNS erreichbar gemacht. Das Edge Routing verteilt Anfragen anhand von Health Checks auf die verfügbaren Cluster. Innerhalb jedes Clusters definiert eine HTTPRoute, welcher Host und welcher Pfad an welchen Service weitergeleitet werden.

Beim klassischen Ingress-Modell könnten Controller-spezifische Annotationen zusätzlich festlegen, wie TLS, Weiterleitungen oder Timeout-Verhalten umgesetzt werden. Das erschwert den Vergleich zwischen Clustern. Mit Gateway API lassen sich die workloadnahen Regeln strukturierter abbilden. Die Edge-Konfiguration bleibt dennoch separat: Sie steuert öffentlichen Zugang, Backend-Auswahl und Schutz, während die Route im Cluster die Anwendung auflöst.

FAQ

Ersetzt die Gateway API eine Edge-Plattform?

Nein. Sie modelliert Routing im Kubernetes-Umfeld. DNS, Anycast, DDoS-Schutz, Edge-TLS, Backend-Failover und öffentliche Erreichbarkeit bleiben eigenständige Verantwortungsbereiche.

Muss die ayedo Edge Cloud mit Managed Kubernetes betrieben werden?

Nein. Die Kubernetes-native Integration kann auch mit eigenen oder bei anderen Providern betriebenen Kubernetes-Clustern genutzt werden.

Warum nicht direkt auf einen Kubernetes-Service routen?

Ein vorgelagerter Edge-Eingang kann Backend-Endpunkte abschirmen, Traffic prüfen und verteilen. Dadurch werden öffentliche Erreichbarkeit und workloadnahes HTTP Routing getrennt steuerbar.

Fazit

Kubernetes Gateway API und Edge Routing lösen unterschiedliche Teile desselben öffentlichen Datenpfads. Gateway und HTTPRoute strukturieren Zuständigkeiten im Cluster; die Edge kontrolliert den externen Eingang, Schutz, Termination und Backend-Verteilung. Diese Trennung ist besonders wertvoll bei mehreren Clustern oder Providern. Die ayedo Edge Cloud ordnet sich als eigenständige Edge-Plattform vor diesen Workloads ein und verbindet Kubernetes-native Routing-Modelle mit Anycast, Loadbalancing und betrieblicher Kontrolle.