Gateway API vs. Ingress: Unterschiede, Vergleich und Entscheidung

Cluster-Netzwerk sauber und zukunftsfest aufsetzen? WZ-IT plant und betreibt Kubernetes-Netzwerke: CNI, Gateway API, Load Balancing, DNS und TLS - und private Zugänge über NetBird statt unnötiger Public Exposure. Netzwerk & Secure Access ansehen

Ingress oder Gateway API? Diese Frage stellt sich bei jedem neuen Kubernetes-Cluster - und mit dem Ende von ingress-nginx auch bei vielen bestehenden. Beide APIs erledigen denselben Grundjob: HTTP-Verkehr von außen an die richtigen Services routen. Sie tun es aber grundverschieden. Dieser Artikel erklärt den Unterschied, zeigt, was Ingress strukturell nicht kann, und beantwortet die eigentliche Frage: wann welches die richtige Wahl ist. Stand Juli 2026.

Inhaltsverzeichnis

• Zwei APIs für denselben Job
• Der Kernunterschied: eine Ressource gegen ein Rollenmodell
• Was Ingress ohne Annotationen nicht kann
• Ingress und Gateway API im Vergleich
• Mehr als nur Ingress: auch Service Mesh
• Wann Ingress noch reicht und wann Gateway API

Zwei APIs für denselben Job

Ingress ist seit Jahren der Standardweg, um HTTP- und HTTPS-Verkehr in einen Cluster zu lassen. Die Ingress-Ressource bleibt eine stabile GA-API und wird nicht entfernt - aber sie ist feature-eingefroren. Neue Funktionen im Kubernetes-Netzwerk entstehen ausschließlich in der Gateway API.

Die Gateway API ist der offizielle Nachfolger, entwickelt von derselben SIG Network. Sie ist kein Beta-Experiment: seit v1.0 vom 31. Oktober 2023 GA (Kubernetes-Blog), die aktuelle Version ist v1.5 vom Februar 2026, die den Fokus auf das Überführen weiterer Funktionen in den stabilen Standard-Channel legt (Kubernetes-Blog). Für Produktion gilt der Standard-Channel mit stabilen v1-Ressourcen.

Wichtig zur Abgrenzung: Das viel diskutierte Retirement betrifft ingress-nginx, einen einzelnen Ingress-Controller - nicht die Ingress-API. Diese Verwechslung führt regelmäßig zu falschen Schlüssen. Mehr dazu im Migrations-Leitfaden von ingress-nginx zu Gateway API.

Der Kernunterschied: eine Ressource gegen ein Rollenmodell

Ingress bildet den gesamten Eintrittspunkt in einer einzigen Ressource ab: Hosts, Pfade, TLS und - über Annotationen - alles andere. In einem Cluster, in dem mehrere Teams dieselbe öffentliche Adresse teilen, vermischt das Verantwortlichkeiten: Wer das Ingress-Objekt bearbeitet, fasst zwangsläufig auch Infrastruktur-Belange wie TLS und Listener an.

Die Gateway API trennt diese Belange in ein Rollenmodell aus mehreren Objekttypen (Gateway-API-Rollen):

• GatewayClass - die Vorlage, die ein Infrastruktur-Anbieter oder Controller bereitstellt.
• Gateway - der konkrete Eintrittspunkt mit Listenern, Ports und TLS, verwaltet vom Cluster-Betrieb.
• HTTPRoute (sowie GRPCRoute, TLSRoute) - die Routing-Regeln der Anwendung, verwaltet vom jeweiligen Team.

Damit besitzt jede Rolle genau ihren Ausschnitt: Der Anbieter verantwortet die GatewayClass, der Cluster-Betrieb das Gateway samt TLS-Terminierung, die Anwendungsteams ihre Routen. Das ist kein kosmetischer Unterschied, sondern der Grund, warum die Gateway API in geteilten Clustern sauber funktioniert, wo das Self-Service-Modell von Ingress an seine Grenzen stößt.

Was Ingress ohne Annotationen nicht kann

Ingress kann nativ genau eines gut: Verkehr nach Host und Pfad verteilen. Alles darüber hinaus - Header-basiertes Routing, gewichtetes Traffic-Splitting für Canary-Deployments, Umschreiben von Pfaden, CORS, Rate-Limiting - muss über controller-spezifische Annotationen ausgedrückt werden.

Genau das ist das strukturelle Problem: Diese Annotationen sind nicht standardisiert. Eine nginx.ingress.kubernetes.io/...-Annotation funktioniert bei Traefik oder HAProxy nicht. Die Konfiguration ist damit an einen Controller gebunden - ein Wechsel bedeutet, jede nicht-triviale Regel neu zu schreiben. Das macht Ingress unportabel und erklärt, warum die Ablösung eines eingestellten Controllers so aufwendig ist.

Die Gateway API hebt diese Funktionen in den standardisierten Kern: Header- und Methoden-Matching, gewichtetes Traffic-Splitting über backendRefs-Gewichte und Cross-Namespace-Routing gehören zur Spezifikation, nicht zu proprietären Annotationen. Wo eine Funktion doch implementierungsspezifisch bleibt, wird sie über explizite Policy-Objekte angehängt statt über undurchsichtige String-Annotationen. Das Ergebnis ist über konforme Implementierungen hinweg portabel.

Ingress und Gateway API im Vergleich

Mehr als nur Ingress: auch Service Mesh

Der vielleicht unterschätzte Unterschied: Die Gateway API deckt nicht nur den Nord-Süd-Verkehr ab (von außen in den Cluster, die klassische Ingress-Aufgabe), sondern über die GAMMA-Initiative auch den Ost-West-Verkehr zwischen Services innerhalb des Clusters - also den Anwendungsfall eines Service Mesh.

Dieselben vertrauten Objekttypen wie HTTPRoute konfigurieren damit sowohl den Eingang am Cluster-Rand als auch die Kommunikation zwischen Diensten. Diese Mesh-Unterstützung ist seit v1.1 Teil des Standard-Channels und gilt als GA. Ingress kennt diesen Anwendungsfall gar nicht - es endet am Cluster-Rand. Wer perspektivisch ein Mesh einführen will, bekommt mit der Gateway API ein durchgängiges Modell statt zweier getrennter Konfigurationswelten.

Wann Ingress noch reicht und wann Gateway API

Die ehrliche Antwort ist nicht „immer Gateway API". Für ein einfaches, stabiles Setup - ein Controller, reines Host-/Pfad-Routing, keine geteilten Cluster, kein Änderungsdruck - funktioniert eine bestehende Ingress-Installation technisch weiter und ist schlicht weniger Umbau.

Zur Gateway API sollten Sie greifen, wenn mindestens einer dieser Punkte zutrifft:

• Sie setzen ingress-nginx ein. Der Controller ist seit März 2026 eingestellt, ohne Sicherheits-Patches. Hier ist die Migration ohnehin fällig - dann gleich auf den Nachfolgestandard.
• Sie brauchen fortgeschrittenes Routing. Header-/Methoden-Matching, Canary per Gewichtung, sauberes Cross-Namespace-Routing - nativ statt über Annotations-Basteleien.
• Mehrere Teams teilen einen Cluster. Das Rollenmodell trennt Infrastruktur- und Anwendungs-Belange sauber.
• Portabilität ist Ihnen wichtig. Konfiguration, die nicht an einen einzelnen Controller gekettet ist.
• Ein Service Mesh ist absehbar. Ein durchgängiges Modell für Nord-Süd und Ost-West.

Und selbst wenn heute keiner dieser Punkte zwingt: Da neue Funktionen ausschließlich in der Gateway API entstehen und der offizielle Umstieg über ingress2gateway unterstützt wird, ist sie für neue Cluster die vorausschauende Wahl. Für die praktische Umsetzung des Umstiegs führt der Migrations-Leitfaden von ingress-nginx zu Gateway API Schritt für Schritt durch Tooling, Annotationen und Cutover. Und wer den Umbau ohnehin plant, sollte interne Dienste gar nicht erst öffentlich exponieren, sondern privat über NetBird erreichbar machen.