Ingress NGINX End of Life: Warum wir noch nicht zu Gateway API gewechselt haben

Im November 2025 hat das Kubernetes-Projekt bekanntgegeben, dass ingress-nginx, einer der am weitesten verbreiteten Ingress-Controller in Kubernetes-Clustern weltweit, im März 2026 seinen End-of-Life-Status erreicht.

Der naheliegende Nachfolger schien klar: Gateway API, die Nachfolge-Spezifikation, die die klassische Ingress-Ressource langfristig ablösen soll. Wir haben sie ernsthaft geprüft, uns dagegen entschieden und einen anderen Weg gewählt. Dieses Whitepaper erklärt warum, was wir stattdessen evaluiert haben und wie die Migration über unsere gesamte Kundenbasis verläuft.

Was das End of Life konkret bedeutet

Die Ankündigung des Kubernetes-Projekts lohnt sich genau zu lesen, denn der erste Eindruck ist dramatischer als die Realität.

Bestehende Deployments funktionieren weiterhin. Helm Charts bleiben verfügbar. Container-Images bleiben in der Registry. Das Projekt nimmt keine neuen Features mehr an, aber der Code verschwindet nicht.

Die eigentliche Frage lautete: Was passiert, wenn nach März 2026 eine CVE auftaucht?

Diese Frage beantwortete sich Anfang 2026 von selbst, als Chainguard bekannt gab, einen sicherheitsgepatchten Fork von ingress-nginx zu pflegen. Damit bleibt die CVE-Abdeckung erhalten, was den Migrationsdruck erheblich reduziert. Bei Bekanntwerden des ersten CVEs nach der Archivierung des offiziellen ingress-nginx Projekts werden wir unsere ingress-nginx Deployments von der offiziellen Version auf den Chainguard-Fork umstellen, als Brücke, nicht als Lösung.

Die grundlegende Einschätzung aber bleibt: ingress-nginx wird nicht mehr weiterentwickelt. Neue Infrastruktur darauf aufzubauen ergibt keinen Sinn. Wir brauchen einen Nachfolger.

Warum wir vorerst nicht zu Gateway API gewechselt haben

Die Kubernetes Gateway API, die Spezifikation, die die klassische Ingress-Ressource langfristig ablösen soll, war der erste Kandidat, den wir geprüft haben. Das Fazit: abwarten, vorerst.

Das Helm-Chart-Ökosystem ist oft noch nicht bereit. Viele produktiv eingesetzte Anwendungs-Helm-Charts kennen nur die klassische Ingress-Konfiguration. Ein Cluster-Operator kann Gateway API nicht einfach einschalten; dafür müsste er Dutzende Upstream-Charts anpassen oder forken. Der operative Aufwand lohnt sich nicht.

Die Spezifikation ändert sich noch. Gateway API existiert seit fünf Jahren und hatte in dieser Zeit immer wieder signifikante Änderungen, die man nachholen musste. Implementierungen wie Cilium, Envoy Gateway und Traefik übernehmen diese Änderungen mit unterschiedlichem Tempo. In der Produktion bedeutet das: aktives Management von Inkompatibilitäten zwischen Spec und Implementierung.

TLS-Zertifikatsverwaltung erfordert einen Paradigmenwechsel. Mit klassischem Ingress stellt cert-manager Zertifikate pro Namespace aus, direkt gebunden an die Ingress-Ressource. Mit Gateway API müssen Zertifikate über clusterweite Gateway-Ressourcen verwaltet werden. Der Mechanismus, der namespace-seitige Delegation wieder ermöglicht, GEP-1713 (ListenerSets), war bis Ende Februar 2026 noch als experimental markiert. cert-manager hat dies klar dokumentiert.

Welche Gateway API Implementierung sich als Standard durchsetzen würde, war unklar. Wir wollten uns nicht auf eine Lösung festlegen und sechs Monate später feststellen, dass sich die breitere Community für eine andere entschieden hat, mit besserem Support und stärkerer Entwicklungskadenz.

Unsere Einschätzung: Gateway API ist die richtige Antwort, aber noch nicht jetzt. Envoy Gateway, Cilium Gateway etc. haben wir für eine spätere Evaluation vorgemerkt, sobald ListenerSets GA sind und das Chart-Ökosystem reift.

Damit stand die eigentliche Frage fest: Welcher Ingress-Controller soll heute betrieben werden?

Wie wir über 20 Controller evaluiert haben

Ausgangspunkt war die Kubernetes Gateway API Conformance-Liste, die alle bekannten Ingress- und Gateway-Implementierungen katalogisiert. Gefiltert wurde nach zwei Kriterien: aktive Community und ein glaubwürdiger Weg zu Gateway API. Ein Controller ohne Roadmap in Richtung Gateway API wäre in zwei Jahren das nächste End-of-Life-Problem. Damit schied rund die Hälfte der Kandidaten aus: veraltete Projekte, alpha-only-Konformität, Single-Vendor-Tools mit minimaler Verbreitung.

Was übrig blieb, haben wir anhand von sechs Kriterien bewertet:

* Ausnahmen bestätigen bekanntlich die Regel, so zum Beispiel Envoy Gateway.

Für die Bewertung der Community-Gesundheit haben wir auf die Entwicklung der GitHub-Sternzahl, die Anzahl aktiver Contributor via GitHub Insights und Projektaktivitätsdaten von insights.linuxfoundation.org geachtet. Stagnierende Contributor-Zahlen oder rückläufige Commit-Frequenz waren Ausschlusskriterien, unabhängig vom Funktionsumfang.