Im März 2026 wurde das Projekt kubernetes/ingress-nginx offiziell eingestellt. Nicht verwechseln: Das ist nicht NGINX als Webserver und auch nicht das kommerzielle nginxinc/kubernetes-ingress von F5 — eingestellt wurde der Community-Controller, der jahrelang der Standard-Ingress in den meisten Clustern war. In der Praxis heißt das eines: keine neuen Releases mehr, keine Bugfixes und — kritischer — keine geschlossenen Schwachstellen. Bestehende Installationen nehmen weiter Traffic an, aber das ist jetzt nicht unterstützte Infrastruktur direkt am Rand des Clusters.
Warum es dringend ist: IngressNightmare und Blast Radius
Das ist keine Aufgabe für „nächstes Quartal". Auslöser der Einstellung war IngressNightmare — CVE-2025-1974 mit der Bewertung CVSS 9.8. Der Admission-Webhook des Controllers erlaubte RCE über eine Injektion in die AdmissionReview, und die Standardrechte gewährten Lesezugriff auf alle Secrets des Clusters. Die Kette ist offensichtlich: ein Controller am Eingang, den niemand mehr patcht, plus eine Klasse von Schwachstellen, die alle Secrets auf einmal abfließen lässt. Der Blast Radius ist nicht ein Service, sondern der ganze Cluster. Jeder Tag auf einem eingestellten Controller ist ein akzeptiertes Risiko, das mit jeder neuen, nie behobenen CVE wächst.
Gateway API: eine Rollentrennung, kein neues Logo
Man muss nicht in Panik verfallen und über Nacht alles neu schreiben — aber hinauszögern darf man es auch nicht. Das Zielmodell ist bereits ausgereift: Gateway API wurde in Kubernetes 1.35 stabil. Und es ist nicht „noch ein Ingress mit anderem Logo", sondern ein anderes Verantwortungsmodell.
Das alte Ingress vermischte Infrastruktur und Anwendung in einem Objekt: TLS, Controller-Annotationen und Business-Routing lagen zusammen, Annotationen waren nicht zwischen Controllern portierbar, und das Verhalten hing vom Hersteller ab. Gateway API trennt die Rollen nach Eigentümern:
GatewayClassundGateway— der Eingang und das Infrastrukturverhalten, im Besitz des Plattform-Teams;HTTPRoute— die Traffic-Regeln der Anwendung, im Besitz des Produkt-Teams.
Canary wird jetzt über das Feld weight in der Route selbst gesetzt, nicht über eine Annotation eines bestimmten Controllers, und die Konfiguration ist über Implementierungen hinweg portierbar. Das ist der Hauptgewinn: Man ist nicht mehr Geisel eines einzelnen Annotation-Herstellers.
Wie man migriert: Audit, zwei Stapel, schrittweiser Cutover
Die Migration beginnt mit einem Audit, nicht mit einer Installation. Sortieren Sie alle Ingress-Objekte auf zwei Stapel. Die einfachen (TLS plus Basis-Routing) wandern fast mechanisch nach Gateway + HTTPRoute. Die komplexen — annotationslastige Fälle mit Rewrites, Canary und Canonical-Domains — sind Kandidaten für ein Redesign unter dem Gateway-API-Modell, nicht für eine direkte Portierung; sie fressen die meiste Zeit.
Als Nächstes folgt eine parallele Installation. Stellen Sie den neuen Controller neben den alten und verlagern Sie den Traffic über ingressClassName schrittweise: zuerst non-critical Services, dann critical, zuletzt high-value. Die Routen auf dem neuen Controller sollten unter echtem Traffic geprüft werden, bevor Sie DNS umschalten, nicht danach.
Welchen Controller wählen
Die Wahl der Implementierung hängt von der Plattform ab: Envoy Gateway (CNCF, natives Gateway API), Cilium Gateway (wenn Cilium bereits Ihr CNI ist — eine Control Plane), AWS ALB / Lattice für EKS sowie Traefik oder Contour/Kong. Wenn die Zeit drängt, ist ein gangbarer Zwischenschritt Traefik als Drop-in: Sein Middleware-CRD ersetzt den „Annotation-Zoo" durch wiederverwendbare Objekte (Rate-Limit, Basic-Auth, CORS, Strip-Prefix). Das strategische Ziel bleibt aber Gateway API selbst: Es überlebt einen Controller-Wechsel, anders als Annotationen.
Upgrade-Hygiene nicht vergessen
Die Einstellung von ingress-nginx ist ein Spezialfall einer allgemeineren Krankheit: dem Durchsickern von deprecated APIs bei Upgrades. Machen Sie die Scanner kubent und Pluto zu einem verpflichtenden CI-Schritt vor jedem Cluster-Upgrade — dann sehen Sie die nächste „plötzlich entfernte" Komponente im Voraus, nicht in der Produktion.
„Läuft" ≠ „unterstützt"
Die Frist liegt bereits hinter uns. Das verschiebt die Migration aus der Kategorie „technische Roadmap" in die Kategorie „Risikomanagement": „läuft" ist nicht mehr gleich „unterstützt", und am Rand des Clusters misst sich dieser Unterschied in gestohlenen Secrets.