Kubernetes Gateway API 2026: v1.5, v1.6 und der Abschied von Ingress-NGINX

📷 "599 - Network connect timeout error" by GirlieMac is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

Das Jahr 2026 markiert einen Wendepunkt für das Kubernetes-Netzwerk: Mit dem Ruhestand von Ingress-NGINX im März und zwei großen Releases der Gateway API (v1.5 und v1.6) steht die Ablösung des klassischen Ingress bevor. Dieser Artikel zeigt, was die neuen Versionen bringen, warum der Zeitpunkt günstig ist und wie die Migration gelingt.

Gateway API v1.5: Von Experimental zu Standard

Am 27. Februar 2026 veröffentlichte das SIG Network Gateway API v1.5 – das bislang umfangreichste Release. Erstmals wechselte das Projekt zu einem Release-Train-Modell nach Vorbild von Kubernetes selbst: Zum Stichtag der Feature-Freeze kommen alle fertigen Features ins Release, ohne dass auf einzelne Meilensteine gewartet wird.

Sechs wichtige Features erreichten den Standard Channel (GA-Status):

ListenerSet – Bisher mussten alle Listener direkt im Gateway-Objekt definiert werden. ListenerSet erlaubt es, Listener unabhängig zu definieren und auf ein Gateway zu mergen. Das ist besonders für Multi-Tenant-Szenarien relevant, in denen Plattform- und Anwendungsteams unterschiedliche Listener verwalten. Auch mehr als 64 Listener pro Gateway werden so möglich.
TLSRoute – Ermöglicht routenbasiertes TLS-Weiterleiten ohne HTTP-Bewusstsein, etwa für Datenbankverbindungen oder Message Queues.
HTTPRoute CORS Filter – natives CORS-Handling direkt in der Route, ohne Implementierungs-spezifische Annotationen.
Client Certificate Validation und Certificate Selection – erweiterte TLS-Features für Gateway-Terminierung.
ReferenceGrant – Namespace-übergreifende Referenzen (z. B. Secrets aus anderen Namespaces) werden jetzt nativ abgesichert.

Gateway API v1.6: TCP und UDP erreichen GA

Nur vier Monate später, am 30. Juni 2026, folgte Gateway API v1.6 mit einem weiteren Meilenstein: TCPRoute und UDPRoute wechselten von Experimental zu Standard (v1-API-Version). Damit deckt Gateway API jetzt alle vier Transportschichten (HTTP, TLS, TCP, UDP) stabil ab – ein entscheidender Schritt für Workloads wie Datenbanken, DNS, VoIP, Gaming oder IoT-Telemetrie, die auf rohen L4-Protokollen laufen.

Ein TCPRoute-Beispiel (aus dem Kubernetes-Blog):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: TCP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: TCPRoute
---
apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: tcp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

Zusätzlich führte v1.6 eine Experimentelle API-Gruppen-Trennung ein: Experimentelle Features landen jetzt in einer eigenen API-Gruppe (gateway.networking.x-k8s.io) mit einem X-Präfix. Das macht auf einen Blick sichtbar, welche Ressourcen noch nicht stabil sind.

Seit v1.6 erschienen bereits die Patch-Releases v1.6.1 und v1.6.2 mit Konformitätsverbesserungen und Bugfixes.

Ingress-NGINX geht in Rente – die Migration wird konkret

Der Ruhestand von Ingress-NGINX im März 2026 setzt viele Teams unter Zugzwang. Mit dem ebenfalls im März veröffentlichten Ingress2Gateway 1.0 steht jedoch ein ausgereiftes Migrationswerkzeug bereit: Es übersetzt Ingress-Ressourcen inklusive über 30 Ingress-NGINX-Annotationen (CORS, Path Rewrite, Backend TLS u. v. m.) in äquivalente Gateway-API-Konfiguration. Die Übersetzung wird durch Integrationstests mit echten Controllern in Live-Clustern abgesichert – nicht nur YAML-Struktur, sondern das tatsächliche Laufzeitverhalten.

Warum jetzt umsteigen?

Die Gateway API ist 2026 produktionsreif: Die Kernressourcen GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute und ReferenceGrant liegen alle auf v1 (stabil). Fünf Controller (Contour, Istio, kgateway, NGINX Gateway Fabric, Traefik) haben die v1.6-Konformitätstests bestanden.

Hinzu kommt ein wachsendes Ökosystem: Das Gateway API Inference Extension (ein offizielles SIG-Projekt) bringt token-bewusstes Routing für selbst gehostete KI-Modelle – ein Thema, das auf der KubeCon EU 2026 viel Aufmerksamkeit bekam.

Fazit

Mit den Releases v1.5 und v1.6 hat die Kubernetes Gateway API 2026 einen Reifegrad erreicht, der den Umstieg nicht nur nahelegt, sondern für viele Teams mit dem EOL von Ingress-NGINX zur Notwendigkeit macht. ListenerSet, TCP/UDP-Standard-Routing und die neue Release-Train-Organisation machen die API zukunftssicher. Wer jetzt mit der Planung beginnt und Tools wie Ingress2Gateway nutzt, gestaltet den Übergang kontrolliert statt unter Zeitdruck.