Das Ende von kubernetes/ingress-nginx: Ihr Migrations-Playbook für März 2026
Wie die Diskussion begann
Hallo zusammen, ich teile hier einen Artikel, den ich über das bevorstehende End-of-Life des community-gepflegten kubernetes/ingress-nginx-Controllers im März 2026 geschrieben habe.
Der Beitrag erklärt, warum das wichtig ist (keine künftigen CVE-Patches mehr, Compliance-Probleme), wie Sie mit einem kurzen Audit prüfen, ob Ihre Cluster betroffen sind, und gibt einen Überblick über die praktikabelsten Migrationsoptionen (etwa Traefik oder die Gateway API) je nach Infrastruktur-Setup.
Ich bin gespannt, zu welchen Controllern alle anderen migrieren.
Ich freue mich auch über Ideen, wie sich der Guide verbessern lässt.
Ich wünsche euch allen einen schönen Tag, liebe Kubernauten :)
Nino
Was in den Kommentaren auffiel
Diskussionspunkt 1
Seien wir ehrlich: Viele Leute haben ingress-nginx nie aktualisiert, nachdem es in den ersten Tests einmal lief — diese Organisationen werden einfach bis zum Schluss dabei bleiben.
Diskussionspunkt 2
Das größere Problem in meinem Szenario ist die fehlende Unterstützung in der Gateway-Spec für unseren Multi-Tenant-Anwendungsfall. Weil die Definition der Listener und ihrer Zertifikate am Gateway gebunden ist, müsste ich bei jedem neuen Tenant immer wieder zurückkommen und das Gateway aktualisieren. Ich weiß, dass an einem ListenerSet gearbeitet wird, aber ich kann erst migrieren, wenn das zusammen mit cert-manager funktioniert. https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/ https://gateway-api.sigs.k8s.io/geps/gep-1713/
Diskussionspunkt 3
Zur Info: Ich nutze bereits die Vorab-Version von cert-manager mit XListenerSet-Unterstützung, und sie funktioniert einwandfrei. Das Release 1.20 mit dieser Unterstützung soll heute erscheinen, sofern es nicht verschoben wird. https://cert-manager.io/announcements/2025/11/26/ingress-nginx-eol-and-gateway-api/ Trotzdem überrascht es mich, dass die Gateway API ohne ListenerSets veröffentlicht wurde, die für so gut wie jeden Kunden, den ich je hatte, notwendig sind.
Diskussionspunkt 4
Wir sind letztes Jahr genau denselben Migrationstanz durchgegangen, als wir von einem älteren Ingress-Controller weggezogen sind. Was uns wirklich zu schaffen gemacht hat, war nicht die Wahl des Ersatzes — es war die Discovery-Phase. Wir hatten etwa 60 Namespaces über 8 Cluster verteilt, und niemand wusste so richtig, welche Teams tatsächlich ingress-nginx nutzten, welche andere Controller und welche einfach rohe LoadBalancer. Am Ende haben wir ein kurzes Skript geschrieben, das per kubectl get ingress alles durchsucht und nach der Controller-Klasse grept, und das Ganze dann mit den tatsächlichen Pod-Annotationen abgeglichen. Das hat ewig gedauert, weil wir ständig zwischen den Clustern hin- und herwechseln mussten. Dabei sind uns eine ganze Reihe Schatten-Deployments aufgefallen, an die sich niemand mehr erinnerte. Würde ich es noch einmal machen, würde ich diesen Audit-Teil von Anfang an viel stärker automatisieren. Die gleichen Diagnosebefehle parallel über die gesamte Flotte laufen zu lassen, hätte uns wohl etwa zwei Wochen Discovery-Arbeit erspart. Die eigentliche Migration verlief reibungslos, sobald wir wussten, womit wir es zu tun hatten — die Gateway API hat für unseren Anwendungsfall übrigens großartig funktioniert, besonders wenn man bereits auf einer aktuellen k8s-Version ist.
Diskussionspunkt 5
Klingt so, als wäre das eigentliche Problem dort, dass die Nutzung von CI-Tools wie Argo/Flux nicht konsequent durchgesetzt wird?
Thread-Übersicht
- Ursprüngliches Subreddit: r/kubernetes
- Ursprünglicher Autor: u/neo123every1iskill
- Reddit-Score: 69
- Anzahl Kommentare: 34
- Ursprünglicher Thread: https://medium.com/@housemd/kubernetes-ingress-nginx-eol-march-2026-the-complete-migration-guide-to-replace-ingress-nginx-e8f6e118fb5f