Supportende für Ingress NGINX: Jetzt Migration planen und umsetzen

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.

Was bedeutet das Supportende von Ingress NGINX konkret?

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.

Ingress vs. Gateway API

Der offensichtlichste Unterschied zwischen Ingress und Gateway API ist die klare Separation of Concerns der Gateway-API-Architektur.

• Eine einzelne Ingress-Ressource bündelt sowohl Host-/Pfadregeln und Listener-Ports für das Routing als auch infrastrukturelle Aspekte wie Controller-Konfigurationen.
• Gateway API setzt hingegen auf ein mehrteiliges Modell mit GatewayClass und Gateway im Aufgabenbereich des Plattformmanagements, während Entwickler:innen Routingregeln für ihre Anwendungen über HTTPRoute-Ressourcen definieren.

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"

...

(Vgl.: https://kubernetes.github.io/ingress-nginx/user-guide/tls/#server-side-https-enforcement-through-redirect)

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.

Alternative Ingress-/Gateway-Controller

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.

F5 NGINX Ingress Controller

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

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.

HAProxy

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

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.

Fazit: Zeit zu Handeln

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.