Vergangenen November verkündete das Kubernetes-Projekt die Einstellung des beliebten Ingress-Controllers ingress-nginx. Nach einer Best-Effort Übergangsphase bis März 2026 würde das Projekt ab diesem Zeitpunkt keinerlei Releases, Bugfixes oder Sicherheitsupdates mehr erhalten. Dieser Zeitpunkt ist nun gekommen, und so wollen wir noch einmal die Frage beleuchten: Was kommt nach ingress-nginx?
Warum wurde ingress-nginx abgekündigt?
ingress-nginx ist ein Open-Source-Projekt. Als Referenzimplementierung der Ingress API in Kubernetes gedacht, wurde es über die Jahre für immer mehr Features und Anwendungsfälle erweitert, um seiner Beliebtheit und den sich wandelnden Anforderungen gerecht zu werden. Wie so oft in der Open-Source-Welt lag der Großteil des Aufwands dabei in den Händen sehr weniger aktiver Entwickler.
Im oben verlinkten Artikel auf der Kubernetes-Website ist die Rede von ein bis zwei Entwicklern, die diesen Aufwand unbezahlt(!) nach ihrem Arbeitstag und an Wochenenden gestemmt haben, trotz der immensen Beliebtheit von ingress-nginx.
Ab einem gewissen Punkt wurde dieser Aufwand zu groß, und auch eine angestrebte Implementierung eines Gateway-Controllers als Nachfolger (InGate) schlug aufgrund mangelnder Beteiligung fehl. So blieb keine andere Möglichkeit, als das Projekt nach einer Übergangsphase einzustellen.
Was ist die offizielle Empfehlung für betroffene Nutzer?
Von dieser Entwicklung sind viele Unternehmen und Einzelpersonen mit unzähligen Clustern betroffen. Die Ankündigung enthält Empfehlungen, wie es weitergehen kann: Entweder man migriert seine Cluster von der Ingress API auf die Gateway API, eine modernere und flexiblere alternative API. Oder man migriert vom eingestellten Ingress-Controller ingress-nginx hin zu einem unterstützen Projekt.
Die Kubernetes-Dokumentation listet verschiedene Alternativen für Ingress-Controller und für Gateway-Controller. Wir haben aus diesen Listen einige Alternativen herausgesucht und vergleichen ihre Fähigkeiten und Einschränkungen in diesem Artikel. Die behandelten Alternativen beinhalten die folgenden Projekte:
Zuvor sollten wir aber noch einmal einen Blick auf die Gateway API werfen, die mehr und mehr zum Einsatz kommt, aber nach wie vor nicht jedem geläufig ist.
Was ist die Gateway API?
Die Gateway API ist als flexiblere Alternative der Ingress API konzipiert. Sie baut auf vielen beobachteten Szenarien und Problemen aus der Nutzung der Ingress API auf, und kommt mit vier klaren Designzielen einher:
- Rollenorientierung: Ressourcen der API modellieren verschiedene Rollen in Organisationen
- Portabilität: Die Gateway API ist eine Alternative zur Ingress API, die weiterhin verwendet werden kann
- Ausdrucksstärke: Viele mit der Ingress API nur über Umwege umsetzbare Szenarien sind in der Gateway API unterstützt
- Erweiterbarkeit: CustomResources können die Gateway API an verschiedenen Stellen nach Bedarf erweitern
Konkret implementiert die Gateway API drei Arten von API-Objekten:
- GatewayClasses, die analog zu IngressClasses der Ingress API die Konfiguration und das Verhalten der Instanzen eines Gateway Controllers definieren.
- Gateways, die konkret eine Instanz eines Gateway Controllers definieren.
- xRoutes, die das Routing verschiedener Arten an Netzwerkverkehr definieren (bspw. HTTP, UDP, TCP, GRPC).
Im Sommer letzten Jahres haben wir die Gateway API auf unserem Blog auch schon einmal ausführlicher vorgestellt. Den Artikel findest du hier.
Was sind die Alternativen?
Wie oben bereits erwähnt, haben wir uns für dich 6 Alternativen angeschaut, die alle auch in den Aufzählungen in der Kubernetes Dokumentation zu finden sind. Aspekte unseres Vergleichs waren die für das Routing genutzten Technologien, Konformität zur Gateway API-Spezifikation, Machbarkeit einer Migration von ingress-nginx, und gegebenenfalls Besonderheiten der jeweiligen Lösung.
Alle verglichenen Lösungen sind Open Source, einige werden jedoch hauptsächlich von einem kommerziellen Vendor verwaltet. Du findest die Ergebnisse unseres Vergleichs einmal zusammengefasst in tabellarischer Form, oder ausführlicher im Absatz zum jeweiligen Projekt.
Die Ergebnisse im Überblick
| Projekt | Technologie | Gateway API Konformität | Migrationsaufwand | Besonderheiten |
| Cilium | Envoy | v1.4.0 | Medium | stark mit CNI verwoben |
| Contour | Envoy | v1.3.0 | Medium | wenig neue Features |
| Emissary | Envoy | limitiert | Hoch | kein Conformance-Report |
| Envoy Gateway | Envoy | v1.4.1 | Medium | höhere Komplexität |
| kgateway | Envoy | v1.4.0 | Niedrig | Bietet Migrationswerkzeuge für ingress-nginx |
| Traefik | Custom | v1.4.0 | Niedrig | unterstützt ingress-nginx Annotationen |
Cilium
Cilium als erstes Projekt in unserem Vergleich hat direkt eine besondere Stellung inne. Es ist vor Allem als Container Network Interface (CNI) Plugin bekannt und hat sich in diesem Bereich als de-facto Standard etabliert. Die Ingress- und Gateway API-Funktionalität des Projekts ist dementsprechend stark mit der Netzwerkimplementierung des Clusters verzahnt.
So routet Cilium eingehende Anfragen mithilfe von eBPF an einen Envoy Proxy weiter. Das impliziert gewisse besondere Verhaltensweisen im Detail, die es sich lohnt, anhand der Dokumentation für Ingress und Gateway API einmal zu evaluieren.
Den Migrationsaufwand schätzen wir hierbei als medium ein – beide Implementierungen unterstützen alle gängigen Szenarien, und Cilium besitzt Konformität für v1.4.0 der Gateway API im Experimental Channel der API-Spezifikation.
Contour
Contour wurde ursprünglich von VMware entwickelt und ist einer der gängigen Ingress Controller in der Kubernetes-Welt. Mit CustomResourceDefinitions für umfangreichere Konfiguration ist es in diesem Bereich auch sehr flexibel und unterstützt verschiedenste Szenarien. Hierfür setzt Contour wie einige Projekte in unserem Vergleich auf Envoy, einen cloud-nativen Proxy.
Seit einiger Zeit beobachten Nutzer eine längere Dauer bei der Implementierung neuer Features. So ist z.B. auch noch kein Report zur Konformität mit v1.4.0 der Gateway API verfügbar. Sicherheitsreleases und Softwareupdates geschehen allerdings weiterhin regelmäßig.
Den Migrationsaufwand schätzen wir auch für Contour als medium ein. Der Contour Ingress Controller ist funktional und bietet umfangreiche Möglichkeiten zur Konfiguration, und Konformität mit der Gateway API ist zumindest für v1.3.0 gegeben.
Emissary
Wie Contour baut auch Emissary auf Envoy als Proxy auf und ermöglicht die Konfiguration über CustomResourceDefinitions.
Als einziges Projekt in unserem Vergleich gibt es keinen offiziellen Report bzgl. der Konformität mit der Gateway API. In der Dokumentation von Emissary findet man zumindest Informationen zu einer limitierten Unterstützung der Gateway API-Spezifikation.
Auch deshalb schätzen wir den Migrationsaufwand hier als hoch ein.
Envoy Gateway
Benötigt man die CustomResourceDefinitions von Contour, Emissary oder kgateway nicht, kann man sich auch direkt mit Envoy Gateway auseinandersetzen. Envoy ist als einziges Projekt im Vergleich bereits konform mit v1.4.1 der Gateway API, und als Baustein in den anderen genannten Projekten ist die Funktionalität des Proxys ausreichend bewiesen.
Die Konfiguration Envoys ist dafür etwas komplexer – nicht umsonst haben andere Ingress Controller CustomResourceDefinitions entwickelt, um genau diese Komplexität von Nutzern fernzuhalten. Die Abwägung, die man treffen muss, ist also Konformität und ein leichtgewichtiger, cloud-nativer Proxy auf der einen gegen unter Umständen erhöhte Komplexität im Betrieb auf der anderen Seite.
Den Migrationsaufwand schätzen wir trotzdem als medium ein.
kgateway
Das CNCF-Projekt kgateway, zuvor unter dem Namen Gloo von Solo.io entwickelt, ist laut Projektwebsite das am weitesten verbreitete Gateway in Kubernetes für Microservices und AI-Anwendungen. Hierfür setzt es ebenfalls auf Envoy, und bietet Unterstützung für v1.4.0 der Gateway API.
Der größte Vorteil von kgateway im Kontext zur Einstellung von ingress-nginx sind die Möglichkeiten zur Migration: Mit seinem Fork des Tools ingress2gateway ermöglicht kgateway die Migration von ingress-nginx, inklusive einer Vielzahl der ingress-nginx-spezifischen Annotationen und Konfiguration.
Die Existenz eines Migrationstools und die weite Verbreitung von kgateway ermöglichen eine Migration von ingress-nginx mit niedrigem Aufwand.
Traefik
Den Abschluss unseres Vergleichs bildet Traefik, das sowohl auf Kubernetes als Ingress Controller als auch in Docker-Umgebungen als Reverse-Proxy vielfach eingesetzt wird. Es bietet CustomResourceDefinitions, Annotationen und eine UI für schnelle Einblicke in das Geschehen in Clustern. Hierbei kommt ausnahmsweise nicht Envoy zum Einsatz, Traefik kümmert sich um alle Vorgänge selbst.
Ähnlich wie kgateway bietet auch Traefik Garantien für eine einfache Migration von ingress-nginx, indem es eine wachsende Anzahl an ingress-nginx Annotationen automatisch unterstützt.
In Kombination mit Traefiks Konformität mit v1.4.0 der Gateway API schätzen wir auch in diesem Fall den Migrationsaufwand als niedrig ein.
Wohin soll die Reise gehen?
Die Einstellung von ingress-nginx markiert das Ende eines beliebten und viel genutzten Werkzeugs, gibt aber gleichzeitig einen wichtigen Impuls, die eigene Infrastruktur zu modernisieren. Die gute Nachricht: Der Kubernetes-Ökosystem bietet eine Vielzahl ausgereifter Alternativen, die unterschiedliche Anforderungen und Migrationsszenarien bedienen.
Wer schnell und unkompliziert migrieren möchte, ist mit kgateway oder Traefik gut beraten. Beide bieten konkrete Werkzeuge und Kompatibilität für bestehende ingress-nginx-Konfigurationen und minimieren so den Aufwand für Teams, die keine grundlegende Umstrukturierung anstreben.
Wer ohnehin bereits Cilium als CNI einsetzt oder einen Wechsel plant, kann dessen integrierte Gateway-Funktionalität nutzen und spart sich damit einen zusätzlichen Komponenten im Cluster.
Unabhängig von der gewählten Lösung lohnt es sich, die Migration als Anlass zu nehmen, die eigene Ingress-Architektur grundlegend zu überdenken. Die Gateway API bietet gegenüber der klassischen Ingress API mehr Ausdrucksstärke und Flexibilität und wird langfristig wohl der bevorzugte Standard in Kubernetes-Umgebungen sein.
Am Ende gilt: Es gibt keine universell richtige Antwort. Die beste Alternative hängt von den spezifischen Anforderungen, dem bestehenden Stack und den verfügbaren Ressourcen im eigenen Team ab. Dieser Vergleich soll als Ausgangspunkt dienen – die endgültige Entscheidung liegt bei dir.
0 Kommentare