Ingress-NGINX geht in Rente. Die Kubernetes-Community hat ihre Favoriten längst parat.
Fast ein Jahrzehnt lang galt: Wer einen Kubernetes-Cluster hochzog und Traffic hineinbekommen musste, griff zu Ingress-NGINX. Es war kein offizieller Standard, aber es hätte einer sein können. Als die Maintainer also ankündigten, dass das Projekt im März 2026 in Rente geht, mischte sich in der Community Nostalgie mit Verärgerung und einer Flut von „ok… und was ersetzt es jetzt?“-Threads.
Das Interessante daran: Niemand wurde wirklich überrumpelt. Die Abwendung von Ingress-NGINX vollzog sich schon seit Jahren still, und die Ankündigung der Einstellung machte den Trend nur sichtbar. Operatoren haben längst ihre Favoriten, und viele betreiben diese schon lange vor der Ankündigung in Produktion.
Traefik ist überall — vielleicht mehr, als irgendjemand erwartet hätte
Wenn die Diskussion ein dominierendes Thema hatte, dann wie oft Traefik zur Sprache kam. Operatoren lieben das unkomplizierte Setup, die saubere Integration mit cert-manager und Let's Encrypt sowie die Art, wie es zwischen Ingress und Gateway API steht, ohne am ersten Tag eine Entscheidung zu erzwingen. Dieses zweisprachige Modell ist ein großer Vorteil: Es erlaubt Teams, schrittweise zu migrieren, anstatt Dutzende — oder Hunderte — Manifeste auf einen Schlag umzuschreiben.
Traefiks neue Ingress-NGINX-Kompatibilitätsschicht schadet auch nicht. Ein Drop-in-Pfad, der bestehende Ressourcen nicht anfassen muss, ist genau das, was erschöpfte Plattform-Teams gerade wollen.
Manche beklagten sich über die Preisgestaltung der Enterprise-Edition, aber die Mehrheit nutzte sie überhaupt nicht. Für die meisten Umgebungen deckt die Open-Source-Version alles ab, was sie brauchen.
Envoy Gateway hat seinen Moment
Envoy ist seit Langem der stille Motor hinter weiten Teilen der Cloud-nativen Welt und treibt Istio, Contour, Cilium und die Hälfte der Proxys an, mit denen man interagiert, ohne es zu merken. Envoy Gateway nimmt den Kern und verpackt ihn in einen sauberen, modernen Controller, der direkt um die Gateway API herum gebaut ist.
Die Leute schätzen, dass es schnell läuft, keine Mesh-Komplexität erfordert und keine überraschende Infrastruktur erzeugt. Das Projekt hat eine gesunde Contributor-Kultur, und Operatoren sehen darin ein starkes, zukunftsgerichtetes Gateway mit viel Spielraum.
Für Teams, die etwas Moderneres als NGINX wollen, aber nichts so Schwergewichtiges wie ein Mesh, trifft Envoy Gateway genau den Sweet Spot.
Cilium-Nutzer setzen alles auf Cilium Gateway API
Cilium-Häuser neigen stark zur Konsolidierung. Sie betreiben Cilium bereits als CNI, eBPF-Engine, kube-proxy-Ersatz, BGP-Implementierung und oft als Sicherheitsgrenze. Als Cilium Gateway-API-Support hinzufügte, sahen viele Teams darin eine Chance, Komponenten zu reduzieren, statt neue hinzuzufügen.
Der Reiz ist einfach: weniger Pods, weniger Daemons, weniger Schichten und eine einzige stimmige Datenebene.
Es gibt Lücken — der TCPRoute-Support ist noch nicht vollständig da, und Operatoren vermissen die zentralisierten HTTP-Logs, die sie früher von Ingress-NGINX bekamen —, aber die meisten Nutzer sind zuversichtlich, dass diese Features nachziehen werden. Wenn Ihr Cluster bereits von Cilium angetrieben wird, ist der Sog hin zu dessen Gateway stark.
Istio taucht immer wieder auf — selbst bei Teams, die es nicht als Mesh nutzen
Jedes Mal, wenn jemand Istio erwähnte, antwortete unweigerlich jemand anderes mit „aber das ist ein ganzes Service Mesh“. Und trotzdem betreiben viele Engineers Istio rein wegen seiner Ingress-Fähigkeiten. Keine Sidecars, kein volles Mesh, nur die Gateways.
Operatoren beschrieben Setups mit mehreren Gateways — manche öffentlich, manche privat —, bei denen cert-manager und ExternalDNS die übliche Verrohrung übernehmen. Es ist stabil, flexibel und hat einen klaren Weg zur Gateway API, ohne eine Mesh-Einführung zu erzwingen.
Istios Ruf, schwergewichtig zu sein, passt nicht mehr dazu, wie es heute genutzt wird. Für manche Teams ist es einfach ein gut konstruiertes, kampferprobtes Gateway, das zufällig Mesh-Features besitzt, die nie aktiviert werden.
Contour ist die stille, zuverlässige Option, die immer wieder auftaucht
Contour trendet nicht so laut wie die anderen, hat sich aber einen stetigen Strom an Lob verdient. Es basiert auf Envoy, unterstützt die Gateway API und hat den Ruf, genau auf die Art langweilig zu sein, die Plattform-Teams zu schätzen wissen. Kein Drama, keine Überraschungen, keine heroischen Debugging-Sessions.
Für Operatoren, die etwas Stabiles ohne viel Magie wollen, ist Contour oft die Wahl.
Die HAProxy-Fraktion ist kleiner, aber sehr treu
HAProxy dominiert die Diskussion nicht, aber die Leute, die es betreiben, sind unglaublich überzeugt von ihrer Wahl. Manche nutzen den OpenShift-Router, der auf HAProxy basiert, während andere die Helm-Charts von haproxytech betreiben oder mit dem neuen HAProxy Unified Gateway experimentieren, das sowohl Ingress als auch Gateway API unterstützt.
Seine Performance und Transparenz machen es attraktiv, besonders für Teams, die mit detaillierten Logs leben und sterben.
Überraschend viele Leute nutzen weiterhin nginx-ingress (die F5-Variante)
Einer der verwirrendsten Teile dieses gesamten Wandels ist die Namenskollision zwischen:
- ingress-nginx (der Community-Controller, der eingestellt wird)
- nginx-ingress (der F5/NGINX-Inc.-Controller, weiterhin aktiv gepflegt)
Viele Operatoren planen den Wechsel zum von F5 gepflegten Controller, weil er dem „business as usual“ am nächsten kommt. Wenn Ihr gesamter Cluster bereits NGINX-Annotationen spricht, stört dieser Weg kaum etwas.
Diese Vertrautheit zählt mehr, als irgendjemand zugeben möchte.
Manche Teams verzichten ganz auf Ingress und setzen auf Cloud-native Pfade
Ein kleinerer, aber bemerkenswerter Teil der Operatoren will überhaupt keinen weiteren Controller im Cluster laufen haben. Manche routen über:
- Cloudflare Tunnels
- AWS Load Balancer Controller
- Azure Managed NGINX
- GCP-Load-Balancer
- ALBs mit selektiven nginx-Rewrites
- Kong, Gloo oder KGateway für API-lastige Umgebungen
Das Muster ist einfach: Wenn die Cloud den Entrypoint für Sie übernehmen kann, brauchen Sie vielleicht keine komplette Ingress-Schicht mehr zu pflegen.
Ein echter Unsicherheitsfaktor: Die Gateway API bringt Workflow-Reibung mit sich
Mit Ingress war alles kompakt und freundlich. Devs erstellten ein Objekt, und cert-manager und ExternalDNS übernahmen die Arbeit. Keine zusätzliche Koordination. Keine zusätzlichen Rollen.
Die Gateway API verteilt Verantwortlichkeiten auf mehrere Ressourcen. Zertifikate liegen auf Gateways. Hostnamen liegen auf HTTPRoutes. Load Balancer werden je nach Controller auf unterschiedlichen Schichten erstellt. Und Entwickler verlieren die Fähigkeit, die gesamte Pipeline zu besitzen, sofern ihnen nicht Berechtigungen eingeräumt werden, die viele Plattform-Teams nicht vergeben möchten.
Mehrere Operatoren sagten, sie blieben bei Ingress, nicht weil sie die Gateway API ablehnen, sondern weil sie ihre Workflows auf eine Weise komplizierter macht, die sich unnötig anfühlt.
Die Hoffnung ist, dass HTTPRoutes irgendwann lernen, Zertifikate zu verwalten, was die vermisste Einfachheit zurückbringen würde.
Die Stimmung am Ende: ein bisschen traurig, ein bisschen frustriert, aber schon auf dem Weg nach vorn
Ingress-NGINX prägte jahrelang das Kubernetes-Networking. Es war das Lehrmittel, die Standardantwort, das stille Arbeitstier. Viele Menschen sind sentimental wegen seiner Einstellung, und das ergibt Sinn. Es trieb alles an, vom Homelab bis zu gewaltigen Multicluster-Deployments.
Aber die Zukunft ist bereits da.
- Traefik wird zur pragmatischen ersten Wahl.
- Envoy Gateway ist die zukunftsgerichtete Option.
- Cilium treibt eine integrierte Netzwerkschicht voran.
- Istio schafft sich eine einfachere Gateway-Rolle.
- Contour und HAProxy bleiben stetig und vertrauenswürdig.
- Und Cloud-native Load Balancer ersetzen für manche Teams still vollwertige Ingress-Controller.
Die Einstellung löste keine Panik aus — sie zeigte nur, wohin Operatoren bereits gewechselt waren. Ingress-NGINX hatte eine lange, einflussreiche Laufzeit. Die nächste Generation ist weniger ein Ersatz als vielmehr eine Landschaft starker Alternativen, die schon heute Workloads antreiben.