Gateway API 1.5: Kubernetes-Networking erreicht die nächste Stufe

📷 "Docker HQ, San Francisco, California" by willbuckner is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Im Februar 2026 hat das Kubernetes SIG Network die Version 1.5 der Gateway API veröffentlicht – die bislang größte und bedeutendste Version des Projekts. Sechs wichtige Funktionen, die zuvor nur im Experimental-Channel verfügbar waren, sind nun im Standard-Channel stabil. Für Teams, die Kubernetes-Networking auf Produktionsniveau betreiben, ist dieser Release ein Meilenstein: Er markiert den Übergang der Gateway API von einer vielversprechenden Alternative zum ernstzunehmenden Nachfolger des klassischen Ingress.

Was ist die Gateway API?

Die Gateway API ist der Nachfolger des Kubernetes-Ingress-Ressourcentyps und adressiert dessen jahrelange Schwächen: Eingeschränkte Routing-Funktionen, fehlende Unterstützung für Multi-Tenancy und die Abhängigkeit von proprietären Annotationen. Gateway API führt spezialisierte Rollen ein – Infrastructure Provider, Cluster Operator und Application Developer – und bildet damit reale Teamstrukturen besser ab. Version 1.5 bringt nun gleich sechs lang erwartete Features in den stabilen Standard-Channel.

ListenerSet: Multi-Tenant-Gateways werden real

Der wohl wichtigste Neuzugang ist ListenerSet (GEP-1713). Bisher mussten alle Listener direkt im Gateway-Objekt definiert werden – ein Single Point of Control, der vor allem in Multi-Tenant-Umgebungen schmerzt. Jedes Team, das einen eigenen Hostname oder ein eigenes TLS-Zertifikat benötigte, war auf das Plattform-Team angewiesen.

ListenerSet ändert das grundlegend: Listener können unabhängig vom Gateway in separaten Namespaces definiert und per parentRef an ein zentrales Gateway angebunden werden. Der Gateway-Controller merged die Listener aller referenzierten ListenerSets automatisch zusammen. Plattformteams besitzen das Gateway, Anwendungsteams verwalten ihre eigenen Listener in ihrem Namespace – inklusive eigener TLS-Zertifikate. Auch das bisherige Limit von 64 Listenern pro Gateway entfällt faktisch.

Ein konkretes Beispiel: Ein zentrales Gateway im Namespace infra mit einem HTTP-Listener auf Port 80. Zwei Teams definieren jeweils ein ListenerSet in ihren Namespaces (team-a, team-b) mit eigenen HTTPS-Listenern und Zertifikaten. Der Gateway-Controller merged alle drei – ein Load-Balancer, mehrere Teams, keine Ingress-Controller-Sprawl.

TLSRoute wird stabil

TLSRoute ist nach jahrelanger Experimentierphase nun im Standard-Channel als v1 verfügbar. Es erlaubt das Routen von TLS-Verbindungen basierend auf dem SNI (Server Name Indication)-Feld des TLS-Handshakes – also noch bevor die eigentliche Anwendungsverbindung aufgebaut wird.

Zwei Betriebsmodi stehen zur Wahl: Passthrough – der Datenstrom wird verschlüsselt bis zum Backend durchgereicht, ideal für strikte Security-Anforderungen und Ende-zu-Ende-Verschlüsselung. Terminate – der Gateway entziffert den TLS-Datenstrom und leitet ihn als Klartext an das Backend weiter, nötig, wenn der Gateway selbst HTTP-Header setzen oder Routing-Entscheidungen treffen soll.

Wichtig für bestehende Nutzer: Wer von Gateway API v1.4 oder früher im Experimental-Channel auf v1.5 Standard umsteigt, muss seine vorhandenen TLSRoutes migrieren, da diese in älteren API-Versionen (v1alpha2/v1alpha3) gespeichert sind.

Weitere stabile Features im Überblick

Neben ListenerSet und TLSRoute sind vier weitere Funktionen in den Standard-Channel gewechselt:

HTTPRoute CORS Filter – serverseitige CORS-Konfiguration direkt in der Route, ohne Middleware oder Annotationen.
Client Certificate Validation – gegenseitige TLS-Authentifizierung (mTLS) zwischen Client und Gateway.
Certificate Selection für Gateway TLS Origination – Auswahl des Zertifikats, mit dem der Gateway sich gegenüber dem Backend authentisiert.
ReferenceGrant – wird nach über einem Jahr ohne Änderungen auf v1 gehoben und unterliegt damit dem GA-API-Vertrag (keine Breaking Changes mehr).

Neue Release-Struktur

Mit v1.5 stellt die Gateway API auf ein Release-Train-Modell um. Statt einzelne Features unabhängig voneinander zu releasen, gibt es fixe Stichtage, zu denen alle fertigen Features gemeinsam veröffentlicht werden. Das Vorbild ist der Release-Prozess von Kubernetes selbst, betreut durch SIG Release. Die neu eingeführten Rollen des Release Managers und Release Shadows sollen die Koordination und Qualität der Veröffentlichungen weiter verbessern.

Gute Nachricht für Betreiber: Die Gateway API ist nicht an eine bestimmte Kubernetes-Version gebunden. Ab Kubernetes 1.30 kann die jeweils aktuelle Version installiert werden, ohne den Cluster zu aktualisieren. Zum jetzigen Zeitpunkt sind bereits sieben Implementierungen vollständig konform zu Gateway API v1.5, darunter Envoy Gateway, Cilium, Istio und Contour.

Fazit

Gateway API v1.5 ist ein Quantensprung für das Kubernetes-Networking. Mit ListenerSet und TLSRoute im stabilen Standard-Channel adressiert die API die beiden größten Kritikpunkte am klassischen Ingress: fehlende Multi-Tenancy-Fähigkeiten und unzureichende TLS-Routing-Optionen. Dazu kommt der Zeitpunkt: Mit der Einstellung von Ingress-NGINX Ende März 2026 verlieren viele Teams ihren Standard-Ingress-Controller – der Wechsel zur Gateway API ist nicht nur technisch sinnvoll, sondern wird für immer mehr Betriebsumgebungen alternativlos. Wer Kubernetes betreibt, sollte Gateway API v1.5 auf dem Radar haben und mit der Migration planen beginnen.