Die Ära der Gateway API ist da

Für viele Kubernetes-Teams war Ingress-NGINX über Jahre die Standardlösung. Es war verfügbar, bekannt und umfassend dokumentiert. Es wurde Teil des Kubernetes-Denkmodells: Ingress erstellen, Annotationen hinzufügen, DNS auf den Load Balancer zeigen lassen und weitermachen.

Diese Ära ist vorbei.

Das Kubernetes-Projekt hat die Stilllegung von Ingress-NGINX mit einer klaren Konsequenz angekündigt: Seit März 2026 gibt es keine neuen Releases, keine Bugfixes und keine Updates mehr, um bestehende oder neu entdeckte Sicherheitslücken zu beheben. Bestehende Deployments laufen weiter, und bestehende Artefakte bleiben verfügbar. Doch Verfügbarkeit ist nicht dasselbe wie eine aktiv gewartete Applikation, und dazu betrifft es noch eine der Kernkomponenten. [1]

Diese Unterscheidung ist wichtig. Nichts explodiert über Nacht. Der Traffic fliesst weiter. Dashboards bleiben vielleicht grün. Aber das Risikoprofil ändert sich grundlegend: Eine zentrale Komponente, die den Einlass in ihr Kubernetes-Cluster kontrolliert, erhält keine Upstream-Fixes mehr.

Das ist kein Warnsignal, das Sie ignorieren sollten.

Schon die Archivierung allein wäre Grund genug, eine Migration zu planen. Jüngste Schwachstellen machen die Situation noch konkreter.

Allein im Jahr 2026 wurden mehrere Ingress-NGINX-Schwachstellen offengelegt, darunter CVE-2026-4342 und CVE-2026-3288. Beide betrafen Pfade für NGINX-Konfigurationsinjektionen, die zu beliebiger Codeausführung im Kontext des Ingress-NGINX-Controllers und zur Offenlegung von Secrets führen konnten, auf die der Controller Zugriffe hatte. [2]

Hinzu kam CVE-2026-42945 in NGINX selbst. NVD führt die Schwachstelle für NGINX Plus und NGINX Open Source im Modul ngx_http_rewrite_module mit einem CVSS-4.0-Score von 9,2 und weist darauf hin, dass eine Ausnutzung einen Heap-Buffer-Overflow und unter bestimmten Bedingungen Codeausführung verursachen kann. NGINX veröffentlichte korrigierte Versionen für die eigenen Upstream-Releases und kennzeichnete NGINX 1.30.1+ und 1.31.0+ als nicht verwundbar. [3][4]

Genau darin liegt das operative Problem: Wenn der Upstream-Webserver oder eine Abhängigkeit gepatcht wird, muss ein gewarteter Downstream-Controller den Fix übernehmen, testen, paketieren und veröffentlichen. Das Kubernetes-Projekt Ingress-NGINX hat jedoch bereits erklärt, dass es nach der Stilllegung keine Releases und keine Sicherheitsupdates mehr geben wird.[1][5]

Für eine Komponente, die externen Traffic in den Cluster leitet, Header verarbeitet, TLS terminiert und oft privilegierte Einblicke in Cluster-Ressourcen hat, ist «es läuft noch» keine Sicherheitsstrategie.

Die naheliegende Reaktion lautet: «Dann wechseln wir eben zu einem anderen Ingress Controller.»

In manchen Umgebungen kann das ein sinnvoller Notfallschritt sein. Mit einer langfristigen Plattformentscheidung sollte man ihn jedoch nicht verwechseln. 

Die Kubernetes-Dokumentation ist eindeutig: 

Das Projekt empfiehlt, Gateway API anstelle von Ingress zu verwenden, da Ingress API eingefroren ist. Kubernetes plant zwar derzeit nicht, Ingress zu entfernen. Die grundlegenden Unzulänglichkeiten der API werden jedoch nicht behoben: keine Segregation der Aufgaben, «Annotation Hell», keine saubere Multiprotokoll-Unterstützung, mangelnde Möglichkeiten des Traffic Managements, limitierte Mandantenfähigkeit. [6] 

Das Gateway-API-Projekt formuliert es ebenso klar: 

Gateway API is the successor to the Ingress API.[7]

Genau das ist der strategische Punkt. 

Der Wechsel von Ingress-NGINX zu einer anderen Ingress-Implementierung erfordert weiterhin Engineering-Aufwand, ohne die Gefahr eines Vendor Lock-ins zu reduzieren. Sie müssen produkt-spezifische Einflüsse auf das Lösungsdesign beachten, Annotationen prüfen, controller-spezifisches Verhalten übertragen, Grenzfälle erneut testen, Helm Values überarbeiten, Observability anpassen, Runbooks aktualisieren und die Traffic-Umstellung validieren. Wenn Sie diese Arbeit ohnehin leisten müssen, warum sollten Sie sie in eine API investieren, die Kubernetes selbst als eingefroren bezeichnet? 

Eine reine Ingress-zu-Ingress-Migration kann das unmittelbare Wartungsrisiko reduzieren. Das grössere Problem löst sie jedoch nicht. Das nächste Modernisierungsprojekt wartet weiterhin. 

Gateway API bietet die Chance, nur einmal zu migrieren.

Gateway API wird oft als «der neue Ingress» bezeichnet. Das greift zu kurz. 

Ingress war einfach, aber gerade diese Einfachheit wurde zur Falle. Sobald Teams Redirects, Rewrites, Header-Verarbeitung, Timeouts, Traffic Splitting, externe Authentifizierung oder erweitertes Policy-Verhalten benötigten, griffen sie zu Annotationen. Diese Annotationen waren mächtig, aber auch implementierungsspezifisch: Willkommen in der Annotation-Hölle. Was in einem Controller funktionierte, funktionierte in einem anderen nicht zwangsläufig. Eine einfache Abfrage nach Annotationen ist zudem kaum möglich, was die Arbeit damit zusätzlich erschwert. 

Gateway API verändert dieses Modell. 

Sie trennt Verantwortlichkeiten. Plattformteams definieren gemeinsame Einstiegspunkte (mittels GatewayClass und Gateway). Anwendungsteams definieren die Zugriffspfade auf ihre Applikationen (HTTPRoute). Policies können strukturiert angehängt werden, statt in langen Annotationslisten verborgen zu sein. Der Gateway-API-Migrationsleitfaden nennt dieses Persona-Modell als einen der wesentlichen Unterschiede zu Ingress. [7] 

Das ist nicht nur saubereres YAML. Es ist ein besseres Betriebsmodell für reale Kubernetes-Plattformen. 

Plattformteams können die gemeinsame Sicherheits- und Traffic-Infrastruktur verantworten, während Anwendungsteams die Hoheit über ihre Applikationsrouten behalten. Es gibt weniger unsichere, kopierte Annotationen, eine klarere Aufgabentrennung und einen deutlich besseren Ansatzpunkt für Sicherheitsteams, um konsistente Kontrollen durchzusetzen. Gleichzeitig kommen sich Anwendungsteams nicht gegenseitig in die Quere. 

Die Ingress API wurde nie für mandantenfähige, rollenorientierte Infrastruktur gebaut. Sie stützt sich stark auf proprietäre, herstellerspezifische Annotationen, die Manifeste unübersichtlich machen. 

Airlock Microgateway ist genau für diesen Übergang gebaut: Kubernetes-native Traffic-Verarbeitung kombiniert mit Web Application, und API Protection (WAAP) sowie einen integrierten Identity-Aware Proxy (IAP). 

Die Migration weg von Ingress-NGINX ist nicht nur eine Routing-Migration. Sie ist auch eine Sicherheitsmigration. 

Sie sollte helfen, die Sicherheitsvorgaben der Plattform durchzusetzen: Request Filtering, konsistente Policies, Authentifizierungsintegration und einen unterstützten Update-Pfad für sicherheitskritische Komponenten. 

Airlock Microgateway bringt diese Themen leichtgewichtig und agil näher an die Arbeitsweise moderner Kubernetes-Teams heran: GitOps, CI/CD, Platform Engineering und Security as Code. [8] 

Die Archivierung von Ingress-NGINX bringt auch das Ökosystem in Bewegung. 

Immer mehr Helm Charts bieten Unterstützung für Gateway API, dokumentieren Gateway-API-Pfade oder eröffnen Issues, um den Übergang zu verfolgen. Auch Nutzerinnen und Nutzer des GitLab Charts betrachten Gateway API als bevorzugten Ersatzpfad für Ingress. [9] 

Nicht jedes Chart ist heute schon so weit. Das ist zu erwarten. 

Die Frage ist, wie wir darauf reagieren. Wir können uns darüber beklagen, dass unser bevorzugtes Chart Gateway API noch nicht unterstützt, und dies als Grund für Verzögerungen nutzen. Oder wir verstehen es als Gelegenheit, einen Beitrag zu leisten. 

Viele Open-Source-Helm-Charts akzeptieren Pull Requests. 

So entwickelt sich die Kubernetes-Community weiter: nicht indem sie wartet, bis jedes Chart perfekt ist, sondern indem sie dem Ökosystem hilft, die bessere API zu übernehmen.

Eine gute Migration beginnt nicht damit, YAML blind zu ersetzen. Sie beginnt damit, zu verstehen, was Sie tatsächlich betreiben. 

Identifizieren Sie zunächst, wo Ingress-NGINX verwendet wird. Der Kubernetes-Blog zur Archivierung empfiehlt, mit dem Label Selector app.kubernetes.io/name=ingress-nginx nach Ingress-NGINX-Pods zu suchen. Erfassen Sie anschliessend alle Ingress-Objekte, TLS-Secrets, Hostnames, Pfadregeln, Annotationen, Rewrite-Regeln, Timeouts, Authentifizierungsmechanismen, Custom Snippets sowie die bestehenden Anforderungen an Monitoring und Observability. [1] 

Entscheiden Sie als Nächstes nicht nur, welcher Controller Ingress-NGINX ersetzt, sondern auch, auf welches API-Modell Ihre Plattform künftig standardisieren soll. Für die meisten Teams sollte das Gateway API sein. 

Führen Sie dann Airlock Microgateway als Gateway-API-Implementierung ein. Starten Sie mit Microgateway als Data Plane, um Routing und operatives Verhalten zu validieren. Konvertieren Sie ausgewählte Ingress-Ressourcen in Gateway- und HTTPRoute-Ressourcen. Lassen Sie alte und neue Pfade, wo möglich, parallel laufen. Testen Sie DNS, Zertifikate, Header, Redirects, Applikations-Callbacks, Health Checks und Observability. 

Mit Ingress2Gateway existiert ein Migrationswerkzeug für die Übersetzung von Ingress- nach Gateway API-Ressourcen. Das meiste lässt sich bereits automatisieren. Der Aufwand sinkt dadurch deutlich. [10] 

Sobald das Routing stabil ist, ergänzen Sie dort Sicherheitsfunktionen, egal ob Request Filtering oder Authentifizierung, wo sie relevant sind. Genau dort wird Microgateway mehr als nur ein Ingress-Ersatz. Es wird Teil Ihrer Kubernetes-Sicherheitsarchitektur. 

Schlussendlich entfernen Sie Ingress-NGINX und schicken es damit in den wohlverdienten Ruhestand. 
 

Auch wenn die Entfernung der Ingress API nicht angekündigt wurde, heisst das nicht, dass sie zukunftsfähig ist und bestehen bleibt. 

Ingress API ist eingefroren und Ingress-NGINX ist archiviert. Der Sicherheits-Patch-Zug ist abgefahren. Das Ökosystem bewegt sich in Richtung Gateway API. Und die Kosten der Migration lassen sich nicht für immer aufschieben. 

Die eigentliche Frage lautet also nicht: «Welcher Ingress Controller soll Ingress-NGINX ersetzen?» Die bessere Frage lautet: «Wenn wir diesen Teil der Plattform ohnehin anfassen müssen, warum wechseln wir gleich nicht zu der API, die Kubernetes empfiehlt?»[6] 

Mit Airlock Microgateway machen Sie Ihre Kubernetes-Plattform bereit für die Zukunft: Kubernetes-nativ, Gateway-API-basiert und bei Bedarf erweiterbar um WAAP und identitätsbasierte Sicherheit. 

Ersetzen Sie nicht einfach den alten Controller. 

Nutzen Sie diesen Moment, um Ihre Kubernetes-Plattform zu modernisieren. 

Wechseln Sie von Ingress-NGINX zu Gateway API. Wechseln Sie von Annotations-Wildwuchs zu strukturierten Policies. Wechseln Sie von «es läuft noch» zu «es wird kontinuierlich weiterentwickelt, ist sicher, bereit für die Zukunft und ich erhalte Hersteller-Support».

Quellen: 

[1] Kubernetes Blog: Stilllegung von Ingress-NGINX 

[2] Kubernetes Discuss: Security Advisory CVE-2026-4342 

[3] NVD: CVE-2026-42945 

[4] NGINX Security Advisories 

[5] Kubernetes Ingress-NGINX GitHub Repository 

[6] Kubernetes Dokumentation: Ingress 

[7] Gateway API: Migration von Ingress 

[8] Airlock Microgateway Dokumentation: WAAP und Identity-Aware Proxy 

[9] GitLab Helm Chart Issue: Gateway-API-Unterstützung 

[10] Ingress zu Gateway