Ingress NGINX End-of-Life 2026: Migration zum offiziellen NGINX Ingress Controller
Hilfe! Ingress NGINX ist im März 26 EOL
Wenn ein so zentraler Bestandteil einer Kubernetes-Infrastruktur wie der Ingress NGINX Controller abgekündigt wird, dann ist das mehr als eine Randnotiz. Im März 2026 endet der Support des Projekts – inklusive Sicherheitsfixes. In vielen Unternehmen ist diese Information bisher allerdings kaum angekommen, obwohl sie potenziell sicherheitsrelevant ist. Der Wechsel betrifft nicht nur ein Tool, sondern eine grundlegende Entscheidung: Welcher Ingress Controller soll künftig an der Peripherie des Clusters stehen und die Verantwortung für eingehenden Traffic übernehmen
NGINX selbst hat die Situation bereits klar umrissen: Für langfristigen, produktiven Betrieb bleibt künftig nur noch der NGINX Ingress Controller, der direkt von F5/NGINX entwickelt und gepflegt wird. Die Community-Version „Ingress NGINX“ ist hingegen ein auslaufendes Modell.
Warum die beiden Projekte oft verwechselt werden – und warum das ein Problem ist
Auf den ersten Blick wirken „Ingress NGINX“ und „NGINX Ingress Controller“ wie unterschiedliche Schreibweisen desselben Produkts. Genau das hat jahrelang zu Verwirrung geführt. Tatsächlich unterscheiden sich beide Ansätze aber grundlegend.
Der Community-Controller, also Ingress NGINX, ist ein historisch gewachsenes Projekt. Viele Funktionen wurden über die Jahre mit Annotations erweitert, manches wirkt zusammengesetzt, manches wirkt pragmatisch statt strategisch. Die Flexibilität war seine Stärke – und gleichzeitig die Quelle zahlreicher Komplexitäten.
Der NGINX Ingress Controller verfolgt dagegen eine klare Architektur, bietet stabilere APIs, nutzt eigene CRDs statt Annotation-Hybriden und ermöglicht Features, die im Enterprise-Kontext längst Standard sind: etwa saubere mTLS-Konfigurationen, modernes Rate-Limiting oder ausgereifte Routing-Mechanismen für gRPC und WebSockets.
Mit dem nahenden EOL wird das zum echten Risiko: Ein Reverse-Proxy im Perimeter-Segment ohne Sicherheitsupdates ist schlicht nicht vertretbar.
Wie Sie herausfinden, welchen Ingress Controller Ihr Cluster nutzt
Viele Teams sind sich gar nicht sicher, welcher Controller in ihrem Cluster tatsächlich läuft. Die folgende Abfrage gibt zumindest einen ersten Hinweis:
kubectl get pods -n ingress-nginx \
-o jsonpath='{.items[*].metadata.labels.app\.kubernetes\.io\/name}'
- „ingress-nginx“ weist auf den auslaufenden Community-Controller hin.
- „nginx-ingress“ oder Varianten davon deuten auf den offiziellen Controller.
Aber Vorsicht: In der Praxis haben sich Label-Fehler, Legacy-Konfigurationen und Helm-Upgrade-Artefakte angesammelt. Deshalb lohnt es sich, zusätzlich Deployments, Images und Helm charts manuell zu prüfen.
Warum die Migration kein “copy & paste” ist
Die beiden Controller denken und konfigurieren sich unterschiedlich.
Das wird vor allem beim Thema Annotations vs. CRDs deutlich.
Der Community-Controller basierte stark auf Annotations, von denen über die Jahre ein regelrechter Wildwuchs entstanden ist. Der offizielle NGINX Ingress Controller verfolgt dagegen ein klar definiertes Modell: Routing, Policies oder TLS-Handling werden über eigene Ressourcenobjekte abgebildet.
Für viele Unternehmen bedeutet das:
Man muss nicht nur die Infrastruktur umstellen, sondern auch das eigene mentale Modell von „wie Ingress funktioniert“.
Wie eine saubere Migration aussieht
NGINX beschreibt den Migrationspfad in mehreren Schritten – aber entscheidend ist vor allem, dass nichts überstürzt wird. Die Erfahrung zeigt, dass viele Ingress-Regeln historisch gewachsen sind. Kaum jemand weiß noch, warum bestimmte Redirects existieren oder welche Annotation eingangs mal einen Bug kompensierte. Deshalb beginnt eine saubere Migration immer mit einer Analysephase.
Sie sollten zuerst prüfen, welche Regeln wirklich notwendig sind, welche Funktionen im neuen Controller anders gelöst werden und welche Abhängigkeiten im Hintergrund still mitlaufen. Viele Teams stellen an dieser Stelle überrascht fest, dass sich veraltete Workarounds angesammelt haben, die längst entfernt werden könnten.
Nach der Analyse folgt die Übersetzung der bestehenden Regeln in die neuen Ressourcen. Der Hersteller bietet dafür tabellarische Zuordnungen an. Trotzdem ist es ratsam, diese Übersetzung nicht blind vorzunehmen, sondern jeden Schritt bewusst zu prüfen – denn manche früheren Annotations funktionieren im neuen Modell völlig anders.
Der sicherste Weg führt über einen Parallelbetrieb: Der neue Controller läuft mit einer eigenen ingressClassName-Konfiguration, während die alten Regeln weiterhin existieren. So lassen sich migrierte Regeln gefahrlos unter einer Staging-Domain testen. Besonders wichtig ist dabei das Verhalten unter Last und bei Protokollen wie WebSockets oder gRPC, die häufig erst in Randfällen Probleme verursachen.
Erst wenn alle Pfade stabil funktionieren, der Traffic sauber fließt und die Logs keine Auffälligkeiten zeigen, lohnt sich der endgültige Umschaltmoment. Danach bleibt nur noch Aufräumen: alte Controller deinstallieren, Annotations aus den Manifests entfernen und veraltete ConfigMaps entsorgen.
Was passiert, wenn Unternehmen nicht migrieren?
Die meisten Probleme zeigen sich nicht sofort am Tag des EOL. Das größere Risiko entsteht schleichend:
Ein Reverse Proxy ohne Security-Patches ist ein wunderbares Angriffsziel, vor allem, wenn er direkt am Internet hängt. Kombiniert mit komplexen Routingregeln oder alten Annotations entsteht schnell eine Angriffsfläche, die kaum jemand auf dem Radar hat.
Hinzu kommt: Ohne laufende Weiterentwicklung kann der Controller mit zukünftigen Kubernetes-Versionen kollidieren. Wer also ohnehin modernisiert, riskiert, dass ein ungewarteter Ingress-Control-Plane-Knoten plötzlich zur Blockade wird.
Kurz gesagt: Wer nicht migriert, schafft bewusst einen Risikopunkt an der empfindlichsten Stelle seines Clusters.
Weitere Infos & Links
Hier gibt es weitere Informationen, um eine erfolgreiche Migration durchzuführen: