Now is the time for Gateway API

For many Kubernetes teams, Ingress-NGINX has been the default answer for years. It was available, well known, and broadly documented. It became part of the mental model of Kubernetes: create an Ingress, add a few annotations, point DNS to the load balancer, and move on. 

That era is over. 

The Kubernetes project announced the retirement of Ingress-NGINX with a clear consequence: after March 2026, there would be no further releases, no bug fixes, and no updates to resolve newly discovered security vulnerabilities. Existing deployments continue to run, and existing artifacts remain available, but that is very different from having a maintained security boundary in front of your applications. [1] 

This distinction matters. Nothing explodes overnight. Traffic still flows. Dashboards may stay green. But the risk profile changes completely. A central component sitting at the edge of your Kubernetes cluster is no longer receiving upstream fixes. 

That is not a warning light you can ignore. 

The retirement would already be enough reason to plan a migration. Recent vulnerabilities make the situation more concrete. 

In 2026, multiple Ingress-NGINX issues were disclosed, including CVE-2026-4342 and CVE-2026-3288. Both involved NGINX configuration injection paths that could lead to arbitrary code execution in the context of the Ingress-NGINX controller and disclosure of Secrets accessible to that controller. [2] 

Then CVE-2026-42945 in NGINX itself. NVD lists it as a vulnerability in NGINX Plus and NGINX Open Source in the ngx_http_rewrite_module, with a CVSS 4.0 score of 9.2, and notes that exploitation can cause a heap buffer overflow and, under certain conditions, code execution. NGINX published fixed versions for its own upstream releases, marking NGINX 1.30.1+ and 1.31.0+ as not vulnerable. [3] [4] 

That is exactly the operational problem: when the upstream web server or a dependency gets patched, a maintained downstream controller must absorb, test, package, and release the fix. But the Kubernetes Ingress-NGINX project has already stated that after retirement there are no more releases and no more security updates. [1] [5] 

For a component that terminates external traffic, handles headers, touches TLS, and often has privileged visibility into cluster resources, 'it still runs' is no longer a security strategy. 

The obvious reaction is: 'Let's switch to another Ingress controller.' 

That may be a valid emergency step in some environments. But it should not be confused with a long-term platform decision. 

The Kubernetes documentation is explicit: the project recommends using Gateway API instead of Ingress, and the Ingress API is frozen. Kubernetes has no current plan to remove Ingress, but the API is no longer being developed and will receive no further feature updates. Therefor the limitation will stay, no segregations of tasks, no multitenancy, no clean multiprotocol support or traffic management, without “annotation hell”.  [6] 

The Gateway API project is equally direct: Gateway API is the successor to the Ingress API. [7] 

This is the strategic point. 

Moving from Ingress-NGINX to another Ingress implementation still requires engineering effort, with the risk of ending in a vendor lock-in again. You must audit annotations, translate controller-specific behavior, retest edge cases, rework Helm values, adapt observability, update runbooks, and validate traffic cutover. If you already have to do that work, why invest it in an API that Kubernetes itself says is frozen? 

A pure Ingress-to-Ingress migration can reduce the immediate maintenance risk, but it leaves the bigger problem unsolved. The next modernization project is still waiting. 

Gateway API is the chance to move once. 

Gateway API is often introduced as 'the new Ingress.' That undersells it. 

Ingress was simple, but its simplicity became a trap. As soon as teams needed redirects, rewrites, header handling, timeouts, traffic splitting, external authentication, or advanced policy behavior, they reached for annotations. Those annotations were powerful, but they were also implementation-specific, welcome to the annotation hell. What worked in one controller did not necessarily work in another and a simple query for annotation is also not possible and makes working with it not easy. 

Gateway API changes the model. 

It separates responsibilities. Platform teams define shared entry points (GatewayClass and Gateway). Application teams define access paths (HTTPRoute). Policies can be attached in a structured way instead of being hidden inside long annotation lists. The Gateway API migration guide calls out this persona model as one of the major differences from Ingress. [7] 

That is not just cleaner YAML. It is a better operating model for real Kubernetes platforms. 

It means platform teams can own the shared security and traffic infrastructure, while application teams keep ownership of their application routes. It means fewer unsafe copy-pasted annotations. It means better separation of duties. And it gives security teams a much better place to attach consistent controls. While the application teams do not interfere with each other. 

Ingress API was never built for multi-tenant, role-oriented infrastructure, as it relies heavily on proprietary, vendor-specific annotations that clutter manifests. 

Airlock Microgateway is built for exactly this transition: Kubernetes-native traffic handling combined with Web Application and API Protection (WAAP) as well as an integrated Identity-Aware Proxy (IAP). 

The migration away from Ingress-NGINX is not only a routing migration. It is also a security migration. 

It should help enforce the security posture of the platform. That includes request filtering, consistent policies, authentication integration, and a supported update path for security-critical components. 

Airlock Microgateway brings those concerns closer to where modern Kubernetes teams already work: GitOps, CI/CD, platform engineering, and 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