Von ingress-nginx zu Gateway API migrieren

Cluster-Netzwerk sicher und zukunftsfest? 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

Wenn Ihr Kubernetes-Cluster HTTP-Traffic über ingress-nginx routet, ist das ein akutes Migrationsthema geworden. Das Community-Projekt wurde eingestellt, und es gibt keine Sicherheits-Patches mehr. Betroffen ist ungefähr die Hälfte aller Kubernetes-Cluster. Dieser Leitfaden zeigt, was passiert ist, warum die Gateway API der richtige Nachfolger ist - und wie Sie ohne Ausfall migrieren. Stand Juli 2026.

Inhaltsverzeichnis

• Was ist passiert: das Ende von ingress-nginx
• Warum nicht einfach ein anderer Ingress-Controller
• Die Gateway API in fünf Minuten
• Der Migrationspfad
• Zero-Downtime-Cutover
• Vier Fallstricke

Was ist passiert: das Ende von ingress-nginx

Am 11. November 2025 kündigten das SIG Network und das Security Response Committee das Retirement von ingress-nginx an (Kubernetes-Blog). Der Kern: Best-Effort-Pflege lief nur noch bis März 2026. Danach gibt es „no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered" - also keine Releases, keine Fehlerbehebungen und keine Sicherheits-Patches mehr.

Bestehende Installationen funktionieren technisch weiter, und die Artefakte bleiben verfügbar. Das ist aber kein Grund zum Abwarten: In einer nachschärfenden Erklärung vom 29. Januar 2026 formulierte das Committee unmissverständlich, dass ein Verbleib bei ingress-nginx nach dem Retirement Betreiber und Nutzer angreifbar macht (Statement). Der Hintergrund erklärt die Dringlichkeit: Ein Controller, der in rund der Hälfte aller Cluster den Traffic annimmt, wurde jahrelang von nur ein bis zwei Freiwilligen gepflegt.

Eine wichtige Abgrenzung, weil sie oft verwechselt wird: Eingestellt ist ausschließlich das Community-Projekt kubernetes/ingress-nginx. Der kommerzielle F5 NGINX Ingress Controller (nginxinc/kubernetes-ingress) ist ein eigenes, weiter gepflegtes Produkt. Und NGINX Gateway Fabric, F5s Gateway-API-Implementierung, ist nochmals ein anderes Projekt. Wer diese drei nicht auseinanderhält, trifft die falsche Migrationsentscheidung.

Warum nicht einfach ein anderer Ingress-Controller

Der naheliegende Reflex ist, den eingestellten Controller durch einen anderen Ingress-Controller zu ersetzen. Kurzfristig geht das - langfristig verschiebt es das Problem nur.

Die Ingress-API selbst ist eingefroren. Sie bleibt zwar als GA-Ressource erhalten und wird nicht entfernt, aber es kommen keine neuen Features mehr hinzu. Die gesamte aktive Weiterentwicklung im Kubernetes-Netzwerk läuft in der Gateway API. Ingress war zudem nie besonders ausdrucksstark: Fast jede über einfaches Host-/Pfad-Routing hinausgehende Funktion musste über controller-spezifische Annotationen abgebildet werden - genau das, was einen Wechsel zwischen Controllern so mühsam macht.

Da bei jeder Ablösung von ingress-nginx ohnehin Migrationsaufwand anfällt, ist die wirtschaftlich sinnvolle Entscheidung, gleich zum Nachfolgestandard zu wechseln, statt in einem Jahr erneut zu migrieren.

Die Gateway API in fünf Minuten

Die Gateway API ist kein Beta-Experiment: Sie ist seit v1.0 vom 31. Oktober 2023 GA und damit seit über zwei Jahren stabil; die aktuelle Version ist v1.5 (Kubernetes-Blog). Für Produktion gilt der Standard-Channel (nur stabile v1-Ressourcen).

Statt einer einzelnen Ingress-Ressource arbeitet die Gateway API mit mehreren, klar getrennten Objekttypen:

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

Dahinter steht ein Rollenmodell: Der Infrastruktur-Anbieter verantwortet die GatewayClass, der Cluster-Betrieb das Gateway samt TLS-Terminierung, die Anwendungsteams ihre HTTPRoutes. Das löst das alte Self-Service-Modell von Ingress ab, das in geteilten Clustern schlecht funktionierte. Zudem ist der Kern ausdrucksstärker - Header- und Methoden-Matching, gewichtetes Traffic-Splitting und Cross-Namespace-Routing gehören zum Standard, nicht zu proprietären Annotationen - und portabel über verschiedene Implementierungen hinweg.

Der Migrationspfad

Der Umstieg läuft in vier Schritten:

1. Inventarisieren. Erfassen Sie alle Ingress-Ressourcen und - entscheidend - die genutzten ingress-nginx-Annotationen. Genau diese Annotationen bestimmen den Aufwand.

2. Zielcontroller wählen. Konform und produktionsrelevant sind unter anderem Envoy Gateway, Cilium Gateway API, Traefik, kgateway (ehemals Gloo) und NGINX Gateway Fabric. Die maßgebliche Auswahlhilfe ist die offizielle Conformance-Liste. Für souveräne, self-hosted Cluster bietet sich Cilium an, wenn es ohnehin als CNI läuft; Envoy Gateway ist ein neutraler Einstieg ohne Bindung an einen bestimmten Datenpfad.

3. Mit ingress2gateway konvertieren. Das offizielle Werkzeug kubernetes-sigs/ingress2gateway übersetzt Ingress-Ressourcen und viele Provider-Annotationen nach Gateway und HTTPRoute - aus dem laufenden Cluster oder aus Manifest-Dateien. Es unterstützt neben ingress-nginx auch cilium, istio, traefik, kong und weitere (README).

4. Manuell nacharbeiten - der eigentliche Aufwand. ingress2gateway ist ausdrücklich nicht dafür gedacht, alle Annotationen zu kopieren. Standard-Fälle wie Canary-Weight, rewrite-target, Redirects, proxy-body-size, CORS oder Source-Range-Filter werden übersetzt. Nicht abgedeckt und daher neu zu bauen sind unter anderem: externe Authentifizierung (auth-url/auth-*), Rate-Limiting, rewrite-target mit Capture-Groups ($1), configuration-snippet/server-snippet (rohe NGINX-Konfiguration) sowie canary-by-cookie und canary-by-header-pattern. Diese Funktionen werden über die implementierungsspezifischen Policies und Filter des gewählten Zielcontrollers nachgebildet - deshalb bestimmt die Controller-Wahl den konkreten Migrationsweg.

Zero-Downtime-Cutover

Der ausfallfreie Umstieg nutzt aus, dass Ingress und Gateway API unabhängige APIs mit eigenen Controllern sind und ein neues Gateway eine eigene LoadBalancer-IP bekommt. Beide laufen also problemlos parallel. Der offizielle Migrations-Guide behandelt bewusst keine Live-Migration - das folgende Muster ist etablierte Praxis:

1. Neuen Gateway-API-Controller und Gateway deployen - es entsteht eine eigene LB-IP.
2. Routen als HTTPRoute nachbauen (Basis über ingress2gateway, dann manuell prüfen und ergänzen).
3. Zertifikate an das Gateway hängen (typischerweise über cert-manager).
4. Auf der neuen IP end-to-end testen, bevor Nutzer umgeleitet werden.
5. Traffic umschalten - per DNS-Cutover mit niedriger TTL oder per gewichtetem Traffic-Splitting über die backendRefs-Gewichte einer HTTPRoute.
6. Den alten Ingress erst nach einer Bewährungsphase abbauen, damit ein schneller Rückweg offen bleibt.

Ein Bare-Metal-Hinweis: Kubernetes 1.36 hat Service.externalIPs als deprecated markiert (wegen CVE-2020-8554). Wer bisher externalIPs als „Poor Man's Load Balancer" nutzt, sollte das Load-Balancing-Fundament vorher sauber auf type: LoadBalancer (etwa MetalLB) stellen und erst darüber das Gateway aufsetzen.

Vier Fallstricke

• Kein Drop-in-Replacement. Das Kubernetes-Committee sagt es selbst: „None of the available alternatives are direct drop-in replacements." Der Aufwand steckt in den Annotationen, die nicht mitwandern - externe Auth, Rate-Limiting, Snippets und Capture-Group-Rewrites müssen neu gebaut werden.
• ingress2gateway-Output nie blind anwenden. Das Tool emittiert nur Gateway und HTTPRoute und warnt bei nicht unterstützten Annotationen. Jedes Ergebnis muss geprüft und getestet werden.
• Conformance ist nicht Feature-Parität. Ein konformer Controller beherrscht die Gateway API, aber nicht automatisch jede ingress-nginx-Funktion. Vor der Wahl gegen die eigene Feature-Liste prüfen.
• Neue LB-IP heißt DNS- und Zertifikatsplanung. Ohne parallelen Betrieb und geplanten Cutover wird aus der Migration ein Ausfall.

Wer die Migration ohnehin angeht, sollte den Moment nutzen, um interne Dienste und die Cluster-API gar nicht erst öffentlich zu exponieren, sondern privat über NetBird erreichbar zu machen. Der zweite große Lifecycle-Umbau 2026 betrifft das Packaging: Helm 3 auf Helm 4 migrieren.