Ratgeber

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.

Von Alec Chizhik 24. Juni 2026 6 Minuten Lesezeit

Ingress-NGINX ist abgekündigt: Der Weg zur Gateway API

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 nicht der fehlende Funktionsumfang, sondern 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.

Sicherheitspatches sind seit dem End-of-Life am 24. März 2026 für ingress-nginx erschienen. Jede neue Lücke im L7-Datenpfad bleibt dauerhaft offen.

Quelle: Kubernetes SIG Network, Security Response Committee

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.

Migrationspfad ohne Downtime

Schritt 1

Bestand inventarisieren. Alle Ingress-Objekte und ihre Annotationen erfassen. Die Liste der Sonderfälle entscheidet später über den Aufwand, nicht die Zahl der Routen.

Schritt 2

CRDs installieren. Die Gateway-API-Ressourcen aus dem Standard-Channel in Version 1.5.1 ausrollen. Das ändert noch nichts am Traffic, es legt nur das Vokabular an.

Schritt 3

Controller wählen und ausrollen. Einen konformen Controller wie Envoy Gateway parallel zum bestehenden ingress-nginx betreiben. Zwei Datenpfade nebeneinander, noch ohne Umschaltung.

Schritt 4

Konvertieren mit ingress2gateway. Das Tool über die Ingress-YAML laufen lassen, es erzeugt Gateway- und HTTPRoute-Objekte. Den Output prüfen, nicht blind anwenden, gerade bei eigenen Annotationen.

Schritt 5

Traffic schrittweise umschalten. Route für Route oder gewichtet über DNS auf den neuen Pfad ziehen, beobachten, dann den alten Controller abbauen. Erst wenn nichts mehr auf ingress-nginx zeigt, ist die Migration fertig.

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.

Mehr aus dem MBF Media Netzwerk

MyBusinessFutureKI im Mittelstand: Der Engpass sitzt in den Altsystemen Digital ChiefsGeopolitik trifft die Datacenter-Roadmap: Was CIOs jetzt absichern SecurityTodayAPI-Security: der blinde Fleck hinter jeder Integration

Bildquelle: KI-generiert (Juli 2026)

Auch verfügbar in

Français English