Die Kubernetes Gateway API ist der Nachfolger des Ingress: eine Familie von Kubernetes-Objekten, mit denen du Verkehr von außen in den Cluster und zwischen Diensten steuerst. Die Kernobjekte GatewayClass, Gateway und HTTPRoute sind seit Version 1.0 (Oktober 2023) stabil, aktuell ist Version 1.6.3. Das Kubernetes-Projekt empfiehlt inzwischen ausdrücklich Gateway statt Ingress. Der Ingress bleibt verfügbar, wird aber nicht mehr weiterentwickelt. Anders als der Ingress ist die Gateway API nicht fest in Kubernetes eingebaut: Du installierst ihre Objekttypen als CRDs und brauchst einen Controller, der sie umsetzt.
Ich betreibe Kubernetes-Cluster in Produktion, auf k3s mit Traefik als Ingress Controller, und habe das Kubernetes-Praxisbuch bei Rheinwerk geschrieben (2024). In diesem Beitrag zeige ich, wie die Gateway API aufgebaut ist, wie sie sich vom Ingress unterscheidet und warum die Frage nach dem Umstieg 2026 dringender geworden ist. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.
Was die Gateway API ist
Die Kubernetes-Dokumentation beschreibt die Gateway API als „Familie von API-Arten“ für dynamische Bereitstellung von Infrastruktur und fortgeschrittenes Routing. Der wichtigste Gedanke dahinter ist die Rollentrennung. Die Objekte sind entlang von drei Rollen geschnitten, die es in vielen Organisationen ohnehin gibt:
Eine GatewayClass sagt, welcher Controller zuständig ist, zum Beispiel Traefik, Envoy Gateway oder der Controller eines Cloud-Anbieters. Ein Gateway ist ein konkreter Einstiegspunkt mit Listenern, etwa HTTPS auf Port 443 für eine Domain. Routen hängen sich an ein Gateway an und beschreiben, welcher Verkehr zu welchem Service geht. Das Anwendungsteam kann seine HTTPRoute ändern, ohne das Gateway anzufassen, und das Cluster-Team legt fest, aus welchen Namespaces Routen überhaupt angehängt werden dürfen.
Gateway API und Ingress im Vergleich
Den Ingress habe ich in Kubernetes Ingress und Ingress Controller ausführlich erklärt. Er bündelt Einstiegspunkt und Routing in einem Objekt und kann im Standard nur Host und Pfad. Alles darüber hinaus, etwa Weiterleitungen, Umschreibungen oder Gewichtung zwischen zwei Versionen, steht in Annotations, und die sind je Controller verschieden. Wer den Controller wechselt, schreibt die Annotations neu.
Zum Status des Ingress ist die Dokumentation eindeutig: „The Ingress API has been frozen.“ Er ist allgemein verfügbar, das Projekt plant nicht, ihn zu entfernen, aber er bekommt keine Änderungen mehr. Du musst also nichts überstürzt umbauen. Neue Funktionen kommen aber nur noch in der Gateway API.
Welche Teile stabil sind
Die Gateway API wird in zwei Kanälen veröffentlicht. Der Standard-Kanal enthält, was als stabil gilt, der Experimental-Kanal neue Funktionen, die sich noch ändern können. Für den Betrieb in Produktion nimmst du den Standard-Kanal. Wichtige Schritte der letzten Versionen laut den Release Notes:
Welche Version du nutzen kannst, hängt nicht nur von den CRDs ab, sondern auch davon, welche Version dein Controller unterstützt. Das ist der Punkt, den du vor jeder Einführung zuerst nachsehen solltest.
Ein Gateway und eine HTTPRoute
So sieht ein minimales Beispiel aus: Ein Gateway nimmt HTTP auf Port 80 an, eine HTTPRoute leitet alles unter shop.example.com an den Service shop weiter, wobei 10 Prozent der Anfragen an eine neue Version gehen.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: web
namespace: infra
spec:
gatewayClassName: beispiel # Name der GatewayClass deines Controllers
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: shop
namespace: shop
spec:
parentRefs:
- name: web
namespace: infra
hostnames:
- shop.example.com
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: shop
port: 80
weight: 90
- name: shop-neu
port: 80
weight: 10
Den Namen der GatewayClass zeigt dir kubectl get gatewayclass. Ob das Gateway angenommen wurde, steht im Status: kubectl describe gateway web -n infra zeigt unter Conditions, ob es Accepted und Programmed ist, und kubectl describe httproute shop -n shop zeigt, ob die Route am Gateway hängt. Fehlt eine dieser Bedingungen, liegt der Fehler fast immer an einem falschen Namen in parentRefs oder an allowedRoutes, die den Namespace nicht zulassen.
Die Gewichtung in backendRefs ist genau die Art Funktion, für die du beim Ingress eine Annotation deines Controllers bräuchtest. Hier steht sie im Standard.
Warum die Frage 2026 dringender ist: das Ende von ingress-nginx
Viele Cluster nutzen ingress-nginx, den Ingress Controller der Kubernetes-Community. Im November 2025 haben SIG Network und das Security Response Committee seinen Ruhestand angekündigt: Wartung nur noch nach Möglichkeit bis März 2026, danach keine Releases, keine Fehlerbehebungen und keine Updates für Sicherheitslücken mehr. Das Repository ist inzwischen archiviert. Bestehende Installationen laufen weiter, aber genau wie beim archivierten Kubernetes Dashboard schließt niemand mehr neue Lücken.
Das Projekt empfiehlt selbst zwei Wege: zur Gateway API wechseln, die es als „modernen Ersatz für Ingress“ bezeichnet, oder, wenn du beim Ingress bleiben musst, einen anderen Ingress Controller nehmen. Wenn du ingress-nginx einsetzt, musst du also ohnehin etwas umbauen. Dann lohnt es sich zu prüfen, ob du nicht gleich auf die Gateway API gehst, statt nur den Controller zu tauschen.
Für die Übersetzung bestehender Ingress-Objekte gibt es ingress2gateway, ein Werkzeug aus dem Gateway-API-Projekt (aktuell v1.2.0). Es übersetzt Ingress-Objekte und einige anbieterspezifische Ressourcen in Gateway-API-Objekte. Annotations kopiert es ausdrücklich nicht einfach mit; was davon in deinem Setup steckt, musst du selbst prüfen. Das Ergebnis ist ein Startpunkt, kein fertiges Manifest.
Gateway API mit k3s und Traefik
k3s liefert Traefik v3 mit, und Traefik unterstützt die Gateway API als Option. Laut k3s-Dokumentation schaltest du sie mit einer HelmChartConfig ein:
apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
name: traefik
namespace: kube-system
spec:
valuesContent: |-
providers:
kubernetesGateway:
enabled: true
Zwei Einschränkungen nennt die Dokumentation (Stand 14.10.2026): Das mitgelieferte Traefik ist mit Gateway API v1.4 kompatibel, für experimentelle Ressourcen wie TCPRoute brauchst du die experimentellen CRDs dieser Version und zusätzlich die Option providers.kubernetesGateway.experimentalChannel=true in den Traefik-Werten. Und vor den k3s-Releases vom April 2026 wurden die Gateway-API-CRDs entfernt, wenn man Traefik nach vorheriger Aktivierung wieder abschaltete. Wenn du eine ältere k3s-Version betreibst, schalte Traefik dann nicht ab, solange Gateway-Ressourcen im Cluster liegen. Die eigenständige Traefik-Dokumentation nennt für die aktuelle Traefik-Version Unterstützung für Gateway API v1.6.3. Welche Traefik-Version in deinem k3s steckt, steht in den Release Notes deiner k3s-Version.
Wann du umsteigen solltest
Meine Einschätzung, passend zu dem, was ich im Ingress-Beitrag geschrieben habe:
- Du nutzt ingress-nginx: Plane den Wechsel jetzt. Prüfe dabei die Gateway API als Ziel, besonders wenn du viele Annotations nutzt.
- Neuer Cluster mit mehreren Teams: Starte mit der Gateway API. Die Rollentrennung zwischen Gateway und Routen zahlt sich aus, sobald mehr als ein Team Routen pflegt.
- Eine Anwendung, eine Domain, TLS, gepflegter Controller: Der Ingress reicht weiter. Umbauen musst du nichts, solange dir die Annotations nicht im Weg stehen.
Häufige Fragen
Ersetzt die Gateway API den Ingress?
Ja, sie ist als Nachfolger gedacht, und das Kubernetes-Projekt empfiehlt Gateway statt Ingress. Der Ingress wird aber nicht entfernt: Er ist eingefroren, bleibt stabil verfügbar und bekommt nur keine neuen Funktionen mehr.
Ist die Gateway API in Kubernetes enthalten?
Nicht fest eingebaut. Die Objekttypen sind CRDs, die du installierst, und ein Controller wie Traefik, Envoy Gateway oder der deines Cloud-Anbieters setzt sie um. Manche Distributionen und Controller bringen die CRDs mit.
Ist die Gateway API produktionsreif?
Die Kernobjekte GatewayClass, Gateway und HTTPRoute sind seit v1.0 im Oktober 2023 stabil, GRPCRoute seit v1.1, TLSRoute seit v1.5, TCPRoute und UDPRoute seit v1.6. Für Produktion nutzt du den Standard-Kanal und prüfst, welche Version dein Controller unterstützt.
Was passiert mit ingress-nginx?
ingress-nginx ist im Ruhestand: Seit März 2026 gibt es keine Releases und keine Sicherheitsupdates mehr, das Repository ist archiviert. Bestehende Installationen laufen weiter, sollten aber auf einen anderen Controller oder auf die Gateway API umgestellt werden.
Was ist der Unterschied zwischen Gateway und GatewayClass?
Die GatewayClass legt fest, welcher Controller zuständig ist, vergleichbar mit der IngressClass. Das Gateway ist ein konkreter Einstiegspunkt dieses Controllers mit Ports, Protokollen und Zertifikaten. An ein Gateway hängen sich dann die Routen der Anwendungen.
Wie du weitermachst
Wenn dir die Grundlagen fehlen, lies zuerst Kubernetes Ingress und Ingress Controller und Kubernetes Service Types erklärt, denn auch die Gateway API leitet an Services weiter, nie direkt an Pods. Wenn du Verkehr nicht nur hinein-, sondern auch innerhalb des Clusters steuern willst, geht es mit Kubernetes Network Policy erklärt weiter.
Wenn du vor dieser Entscheidung stehst und eine zweite Meinung zu deinem Cluster willst, etwa als Cluster-Review, findest du auf meiner Seite Kubernetes-Experte: Beratung und Betrieb, was ich anbiete.
Ingress und Services erkläre ich ausführlich in meinem Kubernetes-Praxisbuch bei Rheinwerk. Die vollständige Spezifikation steht auf der Website des Gateway-API-Projekts, die Einordnung des Kubernetes-Projekts in der Dokumentation zur Gateway API.
