7 Min. Lesezeit

Seit März 2026 ist Ingress-NGINX offiziell am Ende. Keine Patches, keine Security-Updates, keine Bugfixes. Das Kubernetes-Projekt hat den meistgenutzten Ingress Controller der Welt in den Ruhestand geschickt. Rund die Hälfte aller Cloud-native-Umgebungen ist betroffen. Wer jetzt nicht migriert, betreibt internet-exponierte Workloads mit einer aufgegebenen Komponente.

Das Wichtigste in Kürze

• 🚨 Ingress-NGINX ist seit März 2026 End-of-Life. Keine Security-Updates mehr (Kubernetes-Projekt, 11.11.2025).
• 📊 Rund 50 Prozent aller Cloud-native-Umgebungen nutzen Ingress-NGINX (Kubernetes Steering Committee, 29.01.2026).
• ✅ Gateway API v1.4 ist der offizielle Nachfolger. Produktionsreif seit Oktober 2025 (CNCF).
• 🔄 Traefik, HAProxy und F5 NGINX Ingress Controller sind bewährte Community-Alternativen.
• 🏢 KubeCon Europe 2026 in Amsterdam (23. bis 26. März) macht Migration zum Pflichtthema für Platform-Teams.

Was passiert ist und warum es jetzt drängt

Am 11. November 2025 veröffentlichte das Kubernetes-Projekt einen Blogpost zur Einstellung von Ingress-NGINX. Der Controller, seit Jahren der Standard für HTTP-Routing in Kubernetes-Clustern, erhält ab März 2026 keine Updates mehr. Das GitHub-Repository wird read-only und wandert in die Organisation kubernetes-retired.

Was das konkret bedeutet: Jede neue CVE in NGINX oder in der Controller-Logik bleibt ungepatcht. Für einen Controller, der direkt am Internet hängt und den gesamten eingehenden Traffic eines Clusters routet, ist das ein handfestes Sicherheitsrisiko.

Am 29. Januar 2026 legten das Kubernetes Steering Committee und das Security Response Committee gemeinsam nach. In einem offiziellen Statement bezifferten sie die Verbreitung: Rund 50 Prozent aller Cloud-native-Umgebungen setzen Ingress-NGINX ein (Quelle: Datadog Research). Die Empfehlung ist eindeutig: Gateway API als offiziellen Nachfolger evaluieren, Migration planen, nicht warten.

Gateway API: Der offizielle Nachfolger

Die Kubernetes-Community hat die Ablösung seit Jahren vorbereitet. Gateway API ist nicht einfach ein neuer Ingress Controller, sondern ein grundlegend anderes Konzept. Statt einer einzelnen Ingress-Ressource mit Annotationen gibt es jetzt separate Ressourcen für Infrastruktur (GatewayClass, Gateway) und Routing (HTTPRoute, GRPCRoute, TCPRoute).

Seit Oktober 2025 ist Gateway API v1.4.0 im Status General Availability. GatewayClass, Gateway und HTTPRoute sind stabil und produktionsreif. Das ist keine Beta mehr. Unternehmen wie Google, Red Hat und VMware setzen Gateway API bereits in ihren Managed-Kubernetes-Angeboten ein.

Der entscheidende Vorteil: Rollenbasierte Konfiguration. Cluster-Administratoren definieren die Gateway-Infrastruktur, Entwicklerteams konfigurieren ihre Routen unabhängig davon. In Ingress-NGINX war das eine einzige Ressource mit hunderten Annotationen, die nur wenige im Team wirklich verstanden.

„Gateway API modelliert Kubernetes-Netzwerke auf eine ausdrucksstarke, erweiterbare und rollenbasierte Art.“
– Kubernetes-Dokumentation, Gateway API Concepts (sinngemäß)

Die drei besten Alternativen im Vergleich

Gateway API ist die strategisch richtige Wahl. Aber nicht jedes Team kann sofort umsteigen. Je nach Cluster-Setup, Annotationen und Integrationen gibt es unterschiedliche Migrationspfade.

Traefik hat als einer der ersten Controller volle Gateway API v1.4 Unterstützung implementiert. Wer bereits Traefik als Reverse Proxy nutzt, kann den Umstieg mit minimalem Aufwand vollziehen. Traefik Labs bietet eine detaillierte Migrationsanleitung mit Schritt-für-Schritt-Mapping von Ingress-Annotationen auf Gateway-API-Ressourcen.

F5 NGINX Ingress Controller ist der kommerziell gepflegte Fork. Wer bei NGINX bleiben will, ohne auf Community-Support zu verzichten, findet hier die geringste Umstellungsarbeit. Die Konfiguration ist nahezu identisch, nur der Namespace und die Helm-Charts ändern sich. Der Nachteil: Vendor-Lock-in und Lizenzkosten.

HAProxy Ingress Controller ist der stabilste 1:1-Ersatz für Teams, die einen schlanken, bewährten Controller suchen. HAProxy Technologies pflegt den Controller aktiv und hat Gateway-API-Support in der Roadmap.

Migration planen: 5 Schritte für Platform-Teams

Die Migration von Ingress-NGINX ist kein Wochenendprojekt. Platform-Teams sollten strukturiert vorgehen.

Schritt 1: Bestandsaufnahme. Alle Ingress-Ressourcen im Cluster inventarisieren. Welche Annotationen werden genutzt? Welche Custom-Konfigurationen stecken in ConfigMaps? Tools wie Fairwinds Insights können dabei helfen, den Umfang der Migration abzuschätzen.

Schritt 2: Ziel-Controller wählen. Gateway API für Greenfield-Projekte und langfristige Strategie. Traefik oder F5 NGINX für Teams, die schnell umsteigen müssen und bestehende Ingress-Manifeste weitgehend beibehalten wollen.

Schritt 3: Parallel betreiben. Den neuen Controller neben Ingress-NGINX installieren. Traffic schrittweise umleiten, Route für Route. Nicht alles auf einmal umschalten.

Schritt 4: Monitoring anpassen. Ingress-NGINX-spezifische Prometheus-Metriken (nginx_ingress_controller_*) existieren im neuen Controller nicht mehr. Dashboards und Alerts müssen auf die neuen Metriken umgebaut werden.

Schritt 5: Ingress-NGINX deinstallieren. Erst wenn alle Routen migriert sind und der neue Controller stabil läuft. Nicht vorher. Kein Parallelbetrieb auf Dauer, das verdoppelt die Angriffsfläche.

Typische Stolperfallen bei der Migration

Die häufigsten Probleme bei der Ingress-NGINX-Migration betreffen nicht den Controller selbst, sondern das Ökosystem drumherum.

Annotationen ohne Äquivalent. Ingress-NGINX hat über 100 Annotationen, von Rate-Limiting über CORS bis zu Custom-Headers. Nicht alle haben ein direktes Pendant in Gateway API. Teams müssen prüfen, welche Annotationen tatsächlich genutzt werden und ob die Funktionalität im neuen Controller anders abgebildet wird.

cert-manager-Integration. Viele Teams nutzen cert-manager mit Ingress-NGINX für automatische TLS-Zertifikate. cert-manager unterstützt Gateway API nativ seit Version 1.15. Die Migration ist meist unkompliziert, aber die Gateway-Ressourcen brauchen andere Labels als die Ingress-Ressourcen.

External-DNS. Wer External-DNS für automatische DNS-Einträge nutzt, muss prüfen, ob die eingesetzte Version Gateway-API-Ressourcen erkennt. Ältere External-DNS-Versionen arbeiten nur mit Ingress-Objekten.

Custom Error Pages und Snippets. Ingress-NGINX erlaubt Custom-NGINX-Snippets in Annotationen. Das ist mächtig, aber auch ein Sicherheitsrisiko. Gateway API hat bewusst keine vergleichbare Funktion. Teams, die Snippets nutzen, müssen die Logik in den Controller selbst oder in Middleware verlagern.

Warum das Kubernetes-Projekt Ingress-NGINX aufgegeben hat

Die Einstellung von Ingress-NGINX ist kein technisches Versagen, sondern eine strategische Bereinigung. Der Controller wurde 2016 als Referenz-Implementierung gestartet und wuchs über die Jahre zum De-facto-Standard. Doch genau das wurde zum Problem: Über 100 Annotationen, keine klare Rollenverteilung und eine Codebasis, die mit jedem NGINX-Update schwieriger zu pflegen wurde.

Dazu kamen Sicherheitsvorfälle. Im Oktober 2025 veröffentlichte das Kubernetes Security Response Committee einen Bericht über mehrere kritische Schwachstellen im Ingress-NGINX-Admission-Webhook. Die Kombination aus hoher Verbreitung, komplexer Codebasis und schwindender Maintainer-Kapazität machte die Einstellung unvermeidlich.

Für das Kubernetes-Ökosystem ist das ein gesunder Schritt. Gateway API löst nicht nur Ingress-NGINX ab, sondern das gesamte Ingress-Konzept. Statt herstellerspezifischer Annotationen gibt es jetzt standardisierte Ressourcen, die jeder Controller implementieren kann. Das reduziert den Lock-in und macht Kubernetes-Networking portabler.

Was DACH-Unternehmen jetzt priorisieren sollten

Regulierte Branchen in Deutschland, Österreich und der Schweiz stehen unter besonderem Druck. NIS2-pflichtige Unternehmen müssen nachweisen, dass ihre IT-Infrastruktur aktiv gepflegt wird. Ein Ingress Controller ohne Security-Support ist ein dokumentierbares Compliance-Risiko.

Finanzdienstleister und Gesundheitsunternehmen sollten die Migration als erstes angehen. Der Nachweis aktiv gepflegter Komponenten ist Teil der Lieferketten-Dokumentation, die NIS2 verlangt. Wer bei einer Prüfung eine End-of-Life-Komponente am Internet-Perimeter betreibt, hat ein Erklärungsproblem.

Mittelständische Unternehmen mit kleinen Platform-Teams profitieren besonders von Traefik oder F5 NGINX als Zwischenlösung. Die Migration auf Gateway API kann dann als zweiter Schritt erfolgen, wenn Kapazität und Know-how aufgebaut sind.

KubeCon Europe 2026: Migration wird Pflichtthema

Vom 23. bis 26. März 2026 findet die KubeCon Europe in Amsterdam statt. Die Ingress-NGINX-Migration dominiert die Agenda der Platform-Engineering-Tracks. Für Teams, die noch nicht migriert haben, liefert die Konferenz Hands-on-Workshops und Erfahrungsberichte von Unternehmen, die den Umstieg bereits hinter sich haben.

Wer nicht nach Amsterdam fährt: Die Talks werden in der Regel innerhalb von vier Wochen als Aufzeichnung auf YouTube veröffentlicht. Aber warten ist keine Strategie. Jeder Tag ohne Security-Updates ist ein Tag mit offenem Risiko.

Fazit

Ingress-NGINX war jahrelang der Standard. Das ist vorbei. Die Einstellung ist keine Überraschung, sondern das Ergebnis einer bewussten Entscheidung der Kubernetes-Community zugunsten von Gateway API. Wer jetzt nicht handelt, betreibt eine sicherheitskritische Komponente ohne Support.

Der pragmatische Weg: Gateway API für neue Projekte und als strategisches Ziel. Traefik oder F5 NGINX als Brückenlösung für Teams, die schnell reagieren müssen. Parallel betreiben, schrittweise migrieren, dann Ingress-NGINX komplett entfernen.

Die Frage ist nicht ob, sondern wie schnell.

Häufige Fragen

Was passiert, wenn ich Ingress-NGINX weiter nutze?

Es funktioniert technisch weiter, aber Sie erhalten keine Security-Updates mehr. Jede neue Schwachstelle in NGINX oder im Controller-Code bleibt ungepatcht. Für internet-exponierte Workloads ist das ein wachsendes Risiko.

Wie lange dauert die Migration auf Gateway API?

Das hängt von der Anzahl der Ingress-Ressourcen und der genutzten Annotationen ab. Für kleine Cluster mit 10 bis 20 Routen ist die Migration in ein bis zwei Wochen machbar. Große Setups mit Custom-Snippets und komplexen Routing-Regeln brauchen vier bis acht Wochen.

Kann ich Gateway API und Ingress-NGINX parallel betreiben?

Ja, das ist sogar empfehlenswert. Installieren Sie den neuen Controller parallel, migrieren Sie Route für Route und entfernen Sie Ingress-NGINX erst, wenn alle Routen stabil laufen.

Ist Traefik besser als Gateway API?

Traefik ist eine Implementierung, Gateway API ist eine Spezifikation. Traefik unterstützt Gateway API v1.4 vollständig. Sie können Traefik als Controller nutzen und gleichzeitig Gateway-API-Ressourcen verwenden. Beides schliesst sich nicht aus.

Was kostet der F5 NGINX Ingress Controller?

F5 bietet den NGINX Ingress Controller in einer kostenlosen Open-Source-Variante und einer kommerziellen Plus-Version an. Die Plus-Version erfordert eine NGINX-Plus-Lizenz, deren Kosten sich nach der Anzahl der Instanzen richten.

Weiterführende Artikel

• Kubernetes Cluster-Governance im Mittelstand – Warum Kontrolle wichtiger wird als Skalierung (cloudmagazin)
• TLS-Zertifikate 2026 – Warum 200-Tage-Laufzeit das Ende des manuellen Managements bedeutet (cloudmagazin)
• Cloud-native Identity – OAuth 2.1, Passkeys und die Zukunft der Authentifizierung (cloudmagazin)

Mehr aus dem MBF Media Netzwerk

• SBOM-Praxischeck – Wie Ihr Unternehmen die Software-Stückliste umsetzt (SecurityToday)
• Cloud-Repatriation 2026 – Warum CIOs Workloads zurückholen (Digital Chiefs)

Quelle Titelbild: Brett Sayles / Pexels