Ingress NGINX wird eingestellt: Migrationsplan für Ihre Kubernetes-Cluster
Ingress NGINX erhält ab März 2026 keine Sicherheitsupdates mehr. Für viele Kubernetes-Cluster ist das der meistgenutzte Weg, Anwendungen ins Netz zu bringen. So prüfen Sie, ob Sie betroffen sind, und planen den Umstieg auf die Gateway API rechtzeitig.
Was ist passiert?
Am 11. November 2025 haben die Kubernetes SIG Network und das Security Response Committee angekündigt, das Projekt Ingress NGINX in den Ruhestand zu schicken. Bis März 2026 gibt es nur noch eine Wartung nach bestem Bemühen. Danach erscheinen keine neuen Releases, keine Bugfixes und keine Patches für neu entdeckte Sicherheitslücken mehr. Die GitHub-Repositories werden schreibgeschützt.
Als Gründe nennt das Projekt vor allem fehlende Maintainer: Über Jahre lag die Arbeit bei ein bis zwei Personen, die das Projekt in ihrer Freizeit betreuten. Dazu kommt technische Schuld. Funktionen, die einst als praktisch galten, sind heute ein Risiko, etwa die „Snippets“-Annotationen, mit denen sich beliebige NGINX-Konfiguration einschleusen lässt. Wie ernst das ist, zeigten bereits die kritischen Lücken rund um den Admission Controller, die im März 2025 unter dem Namen „IngressNightmare“ bekannt wurden.
Auch der geplante Nachfolger InGate wird eingestellt, weil er nie ausgereift genug war. Einen nahtlosen Ersatz gibt es also nicht.
Wichtig: Bestehende Installationen funktionieren weiter, Helm-Charts und Container-Images bleiben verfügbar. Sie laufen nur ohne Sicherheitsnetz.
Warum betrifft Sie das?
Ingress NGINX ist in vielen Clustern der Standard, oft schon seit der ersten Einrichtung und häufig von Dienstleistern oder Vorlagen mitinstalliert. Der Ingress-Controller ist die Komponente, die direkt aus dem Internet erreichbar ist. Eine ungepatchte Schwachstelle an dieser Stelle ist ein Einfallstor in den gesamten Cluster.
Für Unternehmen mit Compliance-Anforderungen kommt hinzu: Software ohne Sicherheitsupdates lässt sich in Audits kaum noch rechtfertigen. Und eine Migration ist kein Versionsupdate, sondern ein Projekt, das Zeit und Budget braucht. Bis März bleiben gut vier Monate, inklusive Jahresende.
Was Sie jetzt tun sollten
- Betroffenheit prüfen: Mit Cluster-Admin-Rechten zeigt dieser Befehl, ob Ingress NGINX läuft:
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx
- Alle Cluster einbeziehen: Prüfen Sie Produktion, Staging und Entwicklung, auch Managed-Cluster bei AKS, EKS oder GKE, bei denen Ingress NGINX nachträglich installiert wurde.
- Konfiguration inventarisieren: Erfassen Sie alle Ingress-Ressourcen und die genutzten
nginx.ingress.kubernetes.io/*-Annotationen. Gerade Rewrites, Snippets, Authentifizierung und Rate-Limits lassen sich nicht eins zu eins übertragen.
kubectl get ingress --all-namespaces -o yaml | grep "nginx.ingress.kubernetes.io" | sort | uniq -c
- Zielarchitektur wählen: Das Kubernetes-Projekt empfiehlt die Gateway API als modernen Nachfolger. Wer vorerst bei Ingress-Ressourcen bleiben muss, findet in der Kubernetes-Dokumentation eine Liste alternativer Ingress-Controller.
- Werkzeuge nutzen: Das Projekt
ingress2gatewayhilft, bestehende Ingress-Ressourcen in Gateway-API-Objekte zu übersetzen. Das Ergebnis sollten Sie trotzdem prüfen und testen. - Migration schrittweise planen: Neuen Controller parallel betreiben, Anwendungen einzeln umziehen, DNS umstellen, alten Controller zuletzt entfernen.
- Budget einplanen: Rechnen Sie mit Aufwand für Analyse, Umbau der Manifeste oder Helm-Charts, Tests und Anpassungen in CI/CD-Pipelines.
Der Migrationspfad in fünf Schritten:
Fazit
Das Ende von Ingress NGINX kommt nicht überraschend, setzt aber eine klare Frist. Wer jetzt inventarisiert und die Migration auf die Gateway API plant, kann sie geordnet umsetzen, statt im Frühjahr unter Zeitdruck zu reagieren. Wenn Sie Unterstützung bei Analyse oder Umsetzung wünschen, sprechen Sie uns an.