Navigieren durch die Ingress-NGINX-Rente

TL;DR

Der ingress-nginx-Controller für Kubernetes wird im März 2026 eingestellt, was erhebliche Risiken für die Betriebsführung mit sich bringt. Organisationen stehen vor der Wahl, entweder zu einem anderen Ingress-Controller wie Contour zu migrieren oder die Gateway API zu implementieren, die eine moderne und zukunftssichere Lösung bietet.

Hauptinhalt

Die Ankündigung über die Einstellung des ingress-nginx-Controllers hat weitreichende Folgen für Infrastrukturteams. Während die Ingress API weiterhin unterstützt wird, bedeutet das Ende des community-gepflegten Controllers, dass Organisationen aktiv werden müssen, um ihre Netzwerkarchitektur zu modernisieren und Sicherheitsrisiken zu vermeiden. Die Entscheidung zwischen zwei Hauptmigrationen ist entscheidend: eine “Lift-and-Shift”-Migration zu einem anderen Ingress-Controller oder der Wechsel zur Gateway API.

Path A: Die “Lift-and-Shift”-Migration

Diese Option ermöglicht es Betreibern, ihre bestehenden Ingress YAML-Ressourcen beizubehalten und lediglich die zugrunde liegende Ingress-Klasse auf einen Envoy-basierten Controller wie Contour umzuschalten. Dies minimiert sofortige Störungen in den Routing-Definitionen. Allerdings müssen alle spezifischen nginx.ingress.kubernetes.io/*-Annotationen manuell in die entsprechenden Annotationen von Contour übersetzt werden, was zusätzlichen Aufwand bedeutet.

Path B: Die architektonische Evolution

Die Gateway API stellt den Nachfolger der Ingress API dar und bietet ein rollenorientiertes Design, das Infrastrukturfragen von der Anwendungsrouting-Logik trennt. Diese API adressiert strukturelle Einschränkungen der bisherigen Ingress-NGINX-Implementierung und standardisiert Funktionen wie Traffic-Splitting und sicheres Routing über Namespaces hinweg. Der Wechsel zur Gateway API erfordert jedoch einen höheren Migrationsaufwand, da Routing-Manifestdateien vollständig neu geschrieben werden müssen.

Technische Details/Implikationen

Die Wahl zwischen diesen beiden Pfaden sollte auf einer neutralen Analyse der Vor- und Nachteile basieren. Bei einer Migration zu Contour (Path A) ist der Aufwand gering bis mittel, da bestehende Annotationen übersetzt werden müssen. In Bezug auf die Betriebsführung bleibt der Ansatz monolithisch und wird von den Betriebsmitarbeitern verwaltet. Im Gegensatz dazu bietet die Gateway API (Path B) eine zukunftssichere Lösung mit aktiver Weiterentwicklung, die auf eine rollenbasierte Verwaltung setzt. Dies ermöglicht es Entwicklern, HTTP-Routen zu verwalten, während das Betriebsteam die Gateway-Ressourcen überwacht.

Die Migration sollte strategisch angegangen werden. Eine gründliche Bestandsaufnahme der aktuellen technischen Schulden ist notwendig, gefolgt von der Nutzung von Tools wie ingress2gateway zur Automatisierung der Übersetzung. Ein inkrementeller Rollout, bei dem zunächst nicht-kritische Workloads migriert werden, kann helfen, Risiken zu minimieren.

Fazit/Ausblick

Die Entscheidung zwischen Contour und der Gateway API hängt von den spezifischen betrieblichen Einschränkungen, den Zeitrahmen für die Migration und den langfristigen architektonischen Zielen der Organisation ab. Während eine kurzfristige Migration zu Contour eine praktische Lösung darstellen kann, bietet die Gateway API eine zukunftssichere und flexible Alternative für Unternehmen, die bereit sind, ihre Plattform zu modernisieren.