Ingress-NGINX ist abgekündigt: Der Weg zur Gateway API
Kubernetes hat ingress-nginx im März 2026 archiviert: keine Sicherheitspatches mehr. So migrieren Sie sauber auf die Gateway API, ohne Downtime.
Am 24. März 2026 hat das Kubernetes-Projekt das Repository von ingress-nginx archiviert. Seitdem gibt es keine Bugfixes und keine Sicherheitspatches mehr, ausgerechnet für den Controller, der den Web-Traffic der meisten Cluster terminiert. Wer noch darauf läuft, betreibt seinen wichtigsten Netzwerk-Baustein ohne Wartung.
Das Wichtigste in Kürze
- Das End-of-Life ist real: Seit dem 24. März 2026 ist ingress-nginx archiviert, ohne Features, ohne Bugfixes, ohne CVE-Patches. Die zugrundeliegende Kubernetes-Ingress-API bleibt, der populäre Community-Controller nicht.
- Die Gateway API ist der vorgezeichnete Nachfolger: Version 1.5.1 ist stabil, mehrere konforme Controller stehen bereit und das Tool ingress2gateway 1.0 konvertiert über 30 Annotationen automatisch.
- Der Aufwand steckt in den Sonderfällen: Der Standardpfad ist mechanisch, aber Auth-Snippets, Session-Affinität und Canary-Regeln müssen Sie von Hand nachbauen.
Verwandt:Kubernetes ändert Regeln: IPVS und Ingress-NGINX weg / Kubernetes als KI-Default-OS: Cluster als Compliance-Frage
Warum die Uhr abgelaufen ist
Die Ankündigung kam im November 2025 von der Kubernetes SIG Network und dem Security Response Committee, ein Folgestatement im Januar 2026 machte den Ernst der Lage deutlich. Im März 2026 endete dann die Best-Effort-Wartung, das GitHub-Repository wurde am 24. März archiviert. Eine lange Schonfrist zum Aussitzen gibt es nicht, der Support ist beendet.
Das eigentliche Problem ist die Sicherheitslage. Neue Lücken werden weiter gefunden, der NGINX-Rift-Heap-Overflow vom Mai 2026 traf auch archivierte Builds. Patches gibt es dafür nicht mehr. Und End-of-Life-Software direkt im Layer-7-Datenpfad löst in Audits nach SOC 2, PCI-DSS oder ISO 27001 automatische Findings aus. Wer Compliance-Nachweise braucht, hat hier ein offenes Flag stehen.
Eine Klarstellung ist wichtig, weil sie oft durcheinandergeht: Die Kubernetes-Ingress-API selbst verschwindet nicht. Sie bleibt allgemein verfügbar, aber sie ist eingefroren. Die aktive Entwicklung ist vollständig zur Gateway API gewandert. Betroffen ist also der konkrete Controller ingress-nginx, nicht das Konzept Ingress an sich.
Was ist die Gateway API? Die Gateway API ist ein Kubernetes-Standard für Layer-7-Routing, der die ältere Ingress-API ablöst. Sie trennt die Rollen zwischen Infrastruktur-Team und Anwendungs-Team sauber, beschreibt Routen deutlich ausdrucksstärker und ist von Grund auf für mehrere Mandanten im selben Cluster gebaut. Seit 2026 ist sie der offizielle Pfad für neuen Netzwerk-Code.
Drei Wege, einer ist der Hauptweg
Vor jedem Team, das noch auf ingress-nginx läuft, liegen drei Optionen. Sie unterscheiden sich weniger in der Technik als im Zeithorizont und in der Frage, wie viel technische Schuld man bereit ist mitzunehmen.
Der erste Weg ist der Umstieg auf die Gateway API. Das ist die Richtung, in die das Ökosystem zeigt und für die meisten Cluster der sauberste Schnitt. Der zweite Weg ist der Wechsel auf einen anderen Ingress-Controller, etwa Traefik, HAProxy, Envoy Gateway oder die kommerzielle F5-NGINX-Variante. Das hält die vertraute Ingress-API am Leben, verschiebt die strategische Entscheidung aber nur. Der dritte Weg ist kommerzieller Sicherheitssupport für die archivierte Version, angeboten von Drittanbietern. Das kauft Zeit für einen geordneten Umzug, löst das Grundproblem aber nicht.
Für neue Plattformen und für alle, die ohnehin eine Modernisierung anstehen haben, fällt die Wahl auf die Gateway API. Die folgende Gegenüberstellung zeigt, warum das so ist und wo die ehrlichen Abstriche liegen.
Was für die Gateway API spricht
- Offizieller Entwicklungspfad, alle neuen Features landen hier
- Saubere Rollentrennung zwischen Infrastruktur und Anwendung
- Ausdrucksstärkere Routen ohne Annotation-Wildwuchs
- Portabel über konforme Controller hinweg
Was noch hakt
- Eigene Annotationen mappen nicht alle 1:1
- Das Team muss ein zweites Ressourcenmodell lernen
- Observability und Dashboards brauchen neue Verkabelung
- Die Reife der Controller schwankt je nach Feature
Die Migration in fünf Schritten
Der gute Teil zuerst: Für den Standardfall ist der Umzug heute mechanisch. Seit dem 20. März 2026 gibt es ingress2gateway in Version 1.0, ein stabiles Tool der SIG Network, das bestehende Ingress-Definitionen samt über 30 verbreiteter Annotationen in Gateway- und HTTPRoute-Objekte übersetzt. Der folgende Ablauf hält die Downtime bei null, wenn man ihn in dieser Reihenfolge geht.
Wo es im Detail klemmt
Die fünf Schritte klingen glatt und für eine Plattform mit sauberen, generischen Ingress-Regeln sind sie es auch. Die Reibung entsteht dort, wo Teams über Jahre Annotationen angesammelt haben, die ingress-nginx-spezifisch waren. Genau diese Stellen übersetzt kein Tool vollständig.
Die häufigsten Stolperstellen lassen sich vorab benennen. Auth-Snippets und externe Authentifizierung müssen auf die Filter-Mechanik der Gateway API umgebaut werden. Sticky Sessions und Session-Affinität sind anders modelliert als über die alten Cookie-Annotationen. Canary-Deployments, die früher per Annotation liefen, wandern in gewichtete HTTPRoute-Regeln. Und alles, was an Custom-Snippets oder eingebetteter NGINX-Konfiguration hing, hat in der neuen Welt bewusst kein direktes Gegenstück. Das ist so gewollt und kein Versäumnis der Gateway API.
Es gibt aber auch einen Gewinn, der sich erst im Betrieb zeigt. Die Rollentrennung der Gateway API erlaubt es, dass ein Plattform-Team das Gateway besitzt und Anwendungs-Teams nur ihre eigenen Routen anlegen, ohne an der gemeinsamen Infrastruktur zu schrauben. Wer die Migration ohnehin fahren muss, kann sie als Anlass nehmen, diese Zuständigkeiten endlich sauber zu schneiden. Aus einer erzwungenen Pflichtübung wird so ein Stück Plattform-Hygiene, das man sonst nie priorisiert hätte.
Häufige Fragen
Muss ich sofort migrieren oder läuft ingress-nginx einfach weiter?
Technisch läuft die letzte Version weiter, sie verschwindet nicht aus dem Cluster. Sie bekommt aber keine Sicherheitsupdates mehr. Jede neue Lücke bleibt offen und in Compliance-Audits zählt End-of-Life-Software im Datenpfad als Finding. Der richtige Zeitpunkt für die Migration ist damit eher gestern als später.
Bleibt die Kubernetes-Ingress-API selbst erhalten?
Ja. Die Ingress-API ist weiterhin allgemein verfügbar, allerdings eingefroren ohne neue Features. Nur der Community-Controller ingress-nginx ist abgekündigt. Wer bei der Ingress-API bleiben will, kann auf einen anderen Controller wechseln, etwa Traefik oder HAProxy.
Was genau macht das Tool ingress2gateway?
Es liest bestehende Ingress-Definitionen ein und erzeugt daraus Gateway- und HTTPRoute-Objekte. Version 1.0 deckt über 30 verbreitete ingress-nginx-Annotationen ab. Für den Standardfall ist die Konvertierung mechanisch, den erzeugten Output sollte man trotzdem vor dem Anwenden prüfen.
Welche Controller sind eine Alternative zur Gateway API?
Wer nicht auf das neue Modell wechseln will, kann ingress-nginx durch Traefik, HAProxy, Envoy Gateway oder die kommerzielle F5-NGINX-Variante ersetzen. Diese behalten die vertraute Ingress-API. Die grundlegende Entscheidung wird damit aber nur aufgeschoben.
Wie halte ich die Downtime beim Umschalten bei null?
Der Schlüssel ist Parallelbetrieb. Den neuen Controller neben ingress-nginx laufen lassen, den Traffic Route für Route oder gewichtet über DNS verschieben und dabei beobachten. Erst wenn keine Last mehr auf dem alten Pfad liegt, wird ingress-nginx abgebaut.
Bildquelle: KI-generiert (Juli 2026)
