Gateway API v1.5 stabilized six features, and Ingress-NGINX is in sunset

Gateway API v1.5 stabilized six features, and Ingress-NGINX is in sunset

For most of a decade, if you ran HTTP traffic in front of a Kubernetes cluster, you almost certainly ran Ingress-NGINX. It was the default, the safe choice, the thing that just worked. That era quietly ended this year. In March 2026, Ingress-NGINX's best-effort maintenance came to a close. No more releases, no more bug fixes, no more security patches. The clusters you run today keep serving traffic, but from here on, any newly discovered vulnerability in that controller stays unpatched. At the same time, its designated replacement, the Kubernetes Gateway API, just had its biggest release yet, pushing six long-requested features into the stable channel. If you are still on Ingress-NGINX, this is no longer a someday topic. It is a real deadline.

What got retired, and what did not

First, separate the two things people conflate. The Ingress API is not dead. It remains a stable, frozen part of Kubernetes, and your existing Ingress resources keep working. What is gone is Ingress-NGINX, the specific implementation of that API. Kubernetes SIG Network and the project's Security Response Committee made the call, and the recommendation is blunt: move to Gateway API, the project's own replacement. The practical consequence is that an unpatched controller at your network edge is a compounding risk. Every quarter you wait, you accumulate exposure you can no longer close.

What v1.5 actually stabilized

Gateway API v1.5 shipped on February 27, 2026, with a v1.5.1 patch following. The release is less about brand-new capabilities and more about promotion, which is exactly what you want from a project that is maturing. Six features moved from Experimental to Standard, the GA channel:

• ListenerSet, which defines listeners independently and merges them onto a Gateway
• TLSRoute, a first-class resource for routing at the TLS layer
• the HTTPRoute CORS filter, putting cross-origin rules on the route
• client certificate validation, or mutual TLS at the gateway
• certificate selection for Gateway TLS origination, picking the upstream certificate
• ReferenceGrant, making cross-namespace backend references explicit

Promoting existing features matters more than it looks. Experimental means it works but may change. Standard means the API is stable and a controller that claims support is expected to honor it. If you have been sitting on Gateway API because the pieces you actually needed were still experimental, that excuse is gone for all six.

ListenerSet and the 64-listener wall

Of the six, ListenerSet is the one that changes what you can build. Before it, every listener lived directly on the Gateway object, and that object caps out around 64 listeners. For a single-team cluster that is plenty. For a multi-tenant platform where each app team wants its own hostname or port on a shared gateway, it is a hard ceiling that forced awkward workarounds.

ListenerSet, tracked as GEP-1713, lets a team define a set of listeners in its own resource and have the gateway controller merge them onto a target Gateway. The platform team owns the Gateway, the app teams own their ListenerSets, and nobody edits the same object at 2am. That is a real ownership boundary, which is most of what multi-tenancy at the edge is about.

One caveat to keep in your back pocket: the listener field on the Gateway itself is still required. A Gateway must carry at least one valid listener directly on it, even when the rest arrive from attached ListenerSets. It is a small gotcha, but it trips people up in exactly the multi-tenant setup where the feature is most useful.

The mTLS and CORS pieces

The other promotions fill the security and policy gaps that push people away from a bare Ingress. Client certificate validation lets the gateway check a client certificate against a set of CA references, with an AllowInsecureFallback mode for the listeners that still need to accept unauthenticated connections. That is mutual TLS without sidecar complexity. TLSRoute finally gives non-HTTP TLS traffic its own routing resource instead of an implementation-specific extension. The HTTPRoute CORS filter moves cross-origin rules into the route definition, and ReferenceGrant turns cross-namespace references from an implicit footgun into an explicit grant.

The release process changed too

It is easy to miss, but v1.5 is also where the project switched to a release-train model. Features land behind a feature-freeze date, and if the documentation is not ready to ship, the feature is not ready to ship. The team added Release Manager and Release Shadow roles, borrowed from how Kubernetes itself does releases. The intent is a predictable cadence, and for a project you are betting your edge traffic on, predictability is worth more than another clever feature.

Where things stand, and when Ingress is enough

As of the current stable channel, the full GA-level list at the spec includes GatewayClass, Gateway, ListenerSet, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy, and ReferenceGrant. Note the last two on that list. TCPRoute and UDPRoute, which handle raw layer-4 traffic for databases, DNS, and IoT telemetry, graduated to Standard in the follow-on v1.6. That means Gateway API now covers the non-HTTP ports too, closing the last "but we also run Postgres through the edge" gap.

There is one asterisk to read into every list like this: this is spec-level GA. Whether your specific controller actually implements a given feature, and at what version, still varies. Envoy Gateway, Istio, Cilium, and Kong all support Gateway API, but the matrix is not uniform. Before you commit to a migration, check the support table for the features you care about.

And a counterpoint, because "just migrate" is bad advice for the wrong cluster. If your edge is a handful of HTTP services, no mTLS, no layer-4, one team, a frozen Ingress is a perfectly reasonable thing to keep running for a while. The pressure is real for the large, multi-tenant, security-sensitive shops. For the small and simple ones, the deadline is one you get to schedule yourself.

The through-line is not that Gateway API finally added cool features. It is that the pieces you have been waiting for to trust it with your edge are now in the stable channel, and the default alternative is no longer maintained. That combination is what turns a "we should look into this" into a ticket with a date on it. If you are on Ingress-NGINX, the honest first step is not a rewrite. It is reading your controller's Gateway API support matrix and seeing which of those six stable features it already gives you.