Kubernetes Gateway API 2026: Der Ingress-Nachfolger wird erwachsen

Die Kubernetes Gateway API hat sich 2026 endgültig als der Nachfolger des traditionellen Ingress-Ressourcentyps etabliert. Mit der Version 1.6, der GA-Freigabe durch AWS für den Load Balancer Controller und einer wachsenden Zahl konformer Implementierungen ist der Zeitpunkt für die Migration von Ingress gekommen. Der Wechsel verspricht nicht nur bessere Typsicherheit und klarere Rollentrennung, sondern vor allem portable Routing-Definitionen, die zwischen Cloud-Anbietern und selbst betriebenen Clustern gleichermaßen funktionieren.

TCPRoute und UDPRoute im Standard-Channel

Mit Gateway API v1.6.0 (Released am 30. Juni 2026) haben TCPRoute und UDPRoute den Sprung in den Standard-Channel geschafft und stehen nun als stabile v1-API-Ressourcen zur Verfügung. Das schließt eine der größten Lücken des bisherigen Ingress-Modells: Während HTTP- und TLS-Traffic bereits seit v1.0 portabel abbildbar waren, mussten rohe TCP/UDP-Workloads wie Datenbanken, DNS, VoIP oder IoT-Telemetrie auf implementierungsspezifische CRDs oder klassische Kubernetes-Services ausweichen. Mit TCPRoute und UDPRoute lassen sich nun alle Protokolle über einheitliche, portable Ressourcen definieren.

Die Migration ist einfach: Statt der bisherigen v1alpha2-Version werden nun v1-Ressourcen im API-Gruppen-Pfad gateway.networking.k8s.io/v1 genutzt. Die alten v1alpha2-Versionen sind mit v1.6 deprekatiert und werden in einem künftigen Release entfernt. Wer bereits TCPRoute oder UDPRoute im Einsatz hat, sollte die Manifeste zeitnah aktualisieren.

AWS setzt auf Gateway API

Ein starkes Signal für die Industrie-Reife kam im März 2026: AWS schaltete die Gateway-API-Unterstützung im AWS Load Balancer Controller auf GA. Der Controller steuert nun sowohl Application Load Balancer (L7) als auch Network Load Balancer (L4) über die standardisierten Gateway-API-Ressourcen – und nicht länger über Ingress-Annotationen. Ein Tippfehler in einer Annotation wie alb.ingress.kubernetes.io/condtions.api-v2 (mit vertauschtem ‘i’) führte bislang lautlos zu einer nicht routenden Konfiguration, weil der Eintrag einfach ignoriert wurde. Die neuen CRDs wie TargetGroupConfiguration, LoadBalancerConfiguration und ListenerRuleConfiguration fangen solche Fehler bereits beim Anwenden ab, da der API-Server die Struktur validiert.

Die strategische Bedeutung der AWS-Unterstützung ist kaum zu überschätzen: Der größte Public-Cloud-Anbieter signalisiert damit, dass der standardisierte, portable API-Ansatz die Zukunft ist – nicht der proprietäre Annotationen-Weg, den AWS selbst über Jahre geprägt hat. Der AWS Load Balancer Controller in Version 3.0.0 kann zudem automatisch TLS-Zertifikate aus dem AWS Certificate Manager beziehen und rotieren, ohne dass manuelle ARN-Updates nötig sind.

Experimentelle Erweiterungen in v1.6: XBackend und API-Gruppen-Trennung

Neben der Graduierung von TCPRoute und UDPRoute bringt v1.6 zwei wichtige Neuerungen im experimentellen Channel. Mit der Einführung einer separaten API-Gruppe gateway.networking.x-k8s.io wird künftig experimentelle von stabiler Funktionalität bereits auf Gruppenebene unterschieden – ein klares Signal für den wachsenden Reifegrad des Projekts.

Das neue XBackend-Resource ermöglicht erstmals externe Ziele als Backend, etwa für Egress-Szenarien zu Cloud-KI-APIs. Damit reagiert das SIG Network auf den wachsenden Bedarf, KI-Workloads mit Gateway API zu routen – ein Thema, das auf der KubeCon EU 2026 intensiv diskutiert wurde.

Das Ressourcenmodell der Gateway API basiert auf drei klar getrennten Ebenen:

• GatewayClass definiert den Provider (Envoy, AWS, Cilium, Istio, NGINX) – verwaltet durch das Plattform-Team.
• Gateway konfiguriert den Load Balancer mit Ports, Protokollen und TLS – verwaltet durch das Infrastruktur-Team.
• Routes (HTTPRoute, GRPCRoute, TCPRoute, UDPRoute, TLSRoute) definieren die Anwendungs-Routing-Regeln – verwaltet durch die Entwickler-Teams.

Diese Rollentrennung ist der entscheidende Fortschritt gegenüber Ingress, wo für Routing-Änderungen meist Cluster-Admin-Rechte nötig waren. Seit Gateway API v1.5 (Februar 2026) ist zudem das Gateway Merging stabil: Mehrere Gateways können sich auf gemeinsame Listener zusammenführen. Das Plattform-Team besitzt den Listener mit Port und TLS-Zertifikat, während Tenant-Teams ihre Routes in eigenen Namespaces daran anbinden – ohne sich gegenseitig zu überschreiben.

Was die Migration von Ingress bringt

Die Vorteile eines Umstiegs auf die Gateway API sind handfest:

• Typensicherheit: CRDs mit Schema-Validierung statt Strings in Annotationen
• Header-basiertes Routing: Nativ im Standard, ohne Provider-spezifische Hacks
• Traffic Splitting: Canary-Deployments als First-Class-Feature von HTTPRoute
• gRPC-Routing: GRPCRoute seit v1.5 fest im Standard-Channel
• Multi-Protokoll-Unterstützung: TCP, UDP, TLS, HTTP und gRPC aus einem Modell
• Portabilität: Die identische HTTPRoute funktioniert auf AWS, Envoy Gateway, Cilium und Istio – nur die GatewayClass ändert sich

Die Migration selbst kann schrittweise erfolgen: Bestehende Ingress-Ressourcen bleiben lauffähig, während parallel HTTPRoutes getestet werden. Der AWS Load Balancer Controller unterstützt beide APIs gleichzeitig, sodass Teams keinem Migrationsdruck ausgesetzt sind. Für Neuanlagen empfiehlt sich jedoch der direkte Einstieg mit der Gateway API.

Fazit

Die Gateway API hat 2026 alle wesentlichen Meilensteine erreicht: TCPRoute und UDPRoute sind stabil, der größte Cloud-Anbieter unterstützt das Modell produktiv, und die Implementierungslandschaft umfasst über 20 konforme Controller. Wer heute ein neues Kubernetes-Cluster aufsetzt, sollte von Beginn an auf die Gateway API setzen – Ingress in neuem Code ist eine technische Altlast. Wer migriert, profitiert von besserer Validierung, klarerer Rollentrennung und portablen Routing-Definitionen, die einen Provider-Wechsel nicht zum Projekt werden lassen.

Quellen

• Kubernetes Blog: Gateway API v1.6 – TCPRoute and UDPRoute Graduate to Standard — Offizielles Kubernetes-Release zu v1.6.0 (August 2026)
• InfoQ: AWS Load Balancer Controller Reaches GA with Kubernetes Gateway API Support — Analyse der AWS-GA-Ankündigung (März 2026)
• AWS Blog: AWS Load Balancer Controller Adds GA Support for Kubernetes Gateway API — Offizielle AWS-Ankündigung (März 2026)
• Luca Berton: Kubernetes Gateway API – Ingress Replacement 2026 Guide — Praxis-Guide mit YAML-Beispielen und Provider-Vergleich (2026)