09.12.2025
9.12.2025
9.12.2025
Die Kubernetes SIG Network und das Security Response Committee haben das Supportende für Ingress NGINX angekündigt. Bis März 2026 erhält somit einer der beliebtesten Ingress-Controller für Kubernetes nur noch Best-Effort-Unterstützung. Warum Du jetzt handeln solltest.
Mit Ingress NGINX als zentralem Gateway für externen Zugriff empfehlen wir eine strukturierte und zeitnahe Migration, um Sicherheitsrisiken sowie Downtime zu minimieren. In diesem Blogbeitrag stellen wir tragfähige Alternativen vor und zeigen dir planbare Migrationspfade auch zum neueren Gateway-API-Standard.
Bereits heute werden Updates nur noch nach dem Best-Effort-Prinzip bereitgestellt. Dabei dürfte es sich hauptsächlich um Sicherheitsupdates handeln. Neue Funktionalitäten werden nicht entwickelt und mit dem endgültigen Supportende im März 2026 entfallen auch weitere Sicherheitsupdates. Damit steht einer der meistgenutzten Kubernetes-Ingress-Controller vor dem Aus.
Es bleiben (Stand November 2025) rund vier Monate für die Migration. Unternehmen sind nun gefragt, frühzeitig einen strukturierten Migrationsplan zu definieren und umzusetzen. Im Fokus stehen dabei geeignete Alternativen sowie die strategische Frage, ob der Wechsel vom klassischen Ingress zum neueren Gateway-API-Standard jetzt der richtige Schritt ist.
Der offensichtlichste Unterschied zwischen Ingress und Gateway API ist die klare Separation of Concerns der Gateway-API-Architektur.
Ein weiterer wesentlicher Unterschied: Gateway API bietet viele erweiterte Funktionen nativ, die bei Ingress-Ressourcen bislang nur über controller-spezifische Annotationen verfügbar waren. Dies ermöglicht einen unkomplizierteren Wechsel des Gateway-Controllers, da die Abhängigkeit der Konfiguration von controller-spezifischen Key-Value-Settings reduziert wird. Ein Beispiel hierfür ist die HTTPS-Weiterleitung.
Während diese in Ingress NGINX mittels der Annotation
...
metadata:
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
...
aktiviert wird, kann sie in der HTTPRoute-Ressource der Gateway API direkt über einen RequestRedirect-Filter konfiguriert werden:
...
spec:
rules:
- filters:
- type: RequestRedirect
requestRedirect:
scheme: https
statusCode: 301
...
(Vgl.: https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#redirects)
Diese und weitere Funktionen sprechen klar für den Gateway-API-Standard gegenüber dem klassischen Ingress. Allerdings ist die Umstellung mit nicht unerheblichem Aufwand verbunden und die Komplexität des Infrastrukturcodes wächst. Da klassische Ingress-Ressourcen auch weiterhin von Kubernetes unterstützt werden, ist eine Migration zu Gateway API nicht zwingend notwendig, aber je nach Anforderungen und Zukunftsplanung sinnvoll. Als Ersatz für Ingress NGINX empfehlen sich aus diesen Gründen insbesondere Controller, die sowohl Ingress als auch Gateway API unterstützen und explizite Migrationspfade von Ingress NGINX bereitstellen. Somit kann eine schrittweise und risikoarme Umstellung ermöglicht werden.
Als Ersatz für Ingress NGINX stehen mehrere Controller zur Auswahl. Welche Lösung die richtige ist, hängt vom konkreten Einsatzszenario ab und erfordert eine individuelle Bewertung für den jeweiligen Use Case. Im Folgenden stellen wir ausgewählte Optionen kompakt und übersichtlich vor.
Naheliegend ist der Einsatz des gleichnamigen NGINX Ingress Controllers von F5. Er punktet mit vielen Ähnlichkeiten zu Ingress NGINX, die meisten Annotationen sind vergleichbar und es existiert ein definierter Migrationspfad zur Unterstützung der Umstellung. Allerdings unterstützt der NGINX Ingress Controller keine Gateway-API-Ressourcen. Für diese ist eine Nutzung des F5 NGINX Gateway Fabric notwendig. Der NGINX Ingress Controller sowie das NGINX Gateway Fabric werden als Open-Source-Software unter der Apache-2.0-Lizenz angeboten und funktionieren mit Open-Source-NGINX (https://github.com/nginx/nginx, BSD-2-Clause Lizenz). Erweiterte Funktionen sind kommerziell beispielsweise über NGINX Plus verfügbar.
Traefik verspricht einen unkomplizierten Wechsel als Drop-In-Lösung mit Unterstützung von Ingress-NGINX-Annotations für bestehende Ingress-Ressourcen. Nach Aktivierung des Ingress NGINX Providers in Traefik können bereits bestehende Ingressdefinitionen (für Ingress NGINX) weiter genutzt werden und im Anschluss auf Traefik-spezifische Konfigurationen umgestellt werden. Traefik Proxy unterstützt dabei sowohl Ingress- als auch Gateway API-Ressourcen. Traefik Proxy ist als Open-Source-Software unter der MIT License verfügbar. Weitere Funktionen wie Traefik Hub oder Supportleistungen sind über Lizenzmodelle verfügbar.
Der HAProxy Ingress Controller wurde als Alternative zu Ingress NGINX entwickelt und orientiert sich beim Annotation-System an dessen Ansatz. Allerdings ist es kein unmittelbares Drop-In-Replacement, da einige Konfigurationen explizit anders funktionieren. Gegenüber Ingress NGINX punktet HAProxy unter anderem mit leistungsfähigem Load Balancing und höherem Durchsatz. Das HAProxy Unified Gateway ermöglicht den parallelen Einsatz von Ingress und Gateway-API-Ressourcen. Allerdings befindet sich dieses noch in der Beta-Phase. Der HAProxy Ingress Controller sowie das HAProxy Unified Gateway werden unter der Apache-2.0-Lizenz angeboten. Weitere Funktionalitäten sind jedoch auch hier kommerziell verfügbar.
Envoy Gateway setzt konsequent auf Gateway API. Für die Migration bestehender Ingress-NGINX-Konfigurationen steht mit "ingress2gateway" ein Tool zur Verfügung, das bestehende Ingress-Ressourcen automatisiert in Envoy-kompatible Gateway-API-Ressourcen überführt. Envoy Gateway ist unter der Apache-2.0-Lizenz verfügbar.
Das bevorstehende Supportende von Ingress NGINX erfordert zeitnahes Handeln: Der Controller-Wechsel sollte bereits heute geplant und schrittweise umgesetzt werden. Gateway API bietet zwar Vorteile bei Governance, Portabilität und Funktionsumfang, erhöht jedoch die Infrastrukturkomplexität. Eine Migration zu Gateway API ist daher in Abhängigkeit der Anforderungen an die Infrastruktur und Plattform zu bewerten. Da klassische Ingress-Ressourcen weiterhin von Kubernetes unterstützt werden, kann der Fokus zunächst auf der Ablösung des NGINX Ingress Controllers gelegt werden.
In der Praxis empfiehlt sich die Auswahl eines Controllers, der sowohl Ingress als auch Gateway API unterstützt und Migrationspfade von Ingress NGINX bietet. So ist ein Wechsel komfortabler möglich und die Einführung von Gateway API kann optional nachgelagert erfolgen.
Auch Du verwendest noch Ingress NGINX als Ingress-Controller oder hast Fragen zu Deiner Kubernetes-Infrastruktur? Kontaktiere uns – wir helfen Dir gerne dabei, Deine Infrastruktur effizient und skalierbar zu gestalten!
Domain Lead Cloud Transformation & Data Infrastructure
Domain Lead Cloud Transformation & Data Infrastructure
b.telligent – das ist Data Analytics, AI, Customer Engagement und Data Visualisation. Das ist Deutschland, Österreich, die Schweiz und Rumänien. Doch das Entscheidende ist unser Team: Menschen mit echter Leidenschaft für Daten, die gemeinsam innovative Lösungen schaffen und Unternehmen nachhaltig voranbringen
Private Networking in Azure erhöht die Sicherheit, bringt aber auch höhere Kosten und mehr Architekturaufwand mit sich. Wir erklären, welche Risiken oft übersehen werden und wann Private Endpoints wirklich sinnvoll sind.
Du willst Deine Infrastruktur mit Terraform verwalten, aber dann passiert es doch, dass Änderungen manuell gemacht wurden – und Du eine Lösung dafür finden musst. Der Umgang damit unterscheidet sich von Fall zu Fall.
Es ist eine große Stärke von Terraform, dass es mit Änderungen außerhalb der von ihm verwalteten Ressourcen umgehen kann. Die Stichworte sind: data, import, removed, ignore_changes, lock, variables.
Kein vorheriger Beitrag
Kein nächster Beitrag
