Gateway API v1.5 Graduates Key Features as Ingress-NGINX Nears Retirement

What happened

Kubernetes networking is hitting a hard transition point in 2026. According to a post on dev.to, the Ingress-NGINX controller is being retired in March, while the Gateway API project has shipped two major releases this year, v1.5 and v1.6 — a combination the author describes as making the replacement of classic Ingress imminent rather than aspirational.

The first of the two, v1.5, arrived on February 27, 2026 from Kubernetes SIG Network and is described as the project's most extensive release so far. v1.6 followed later in the year.

A new release process

v1.5 also marks a process change: the project moved to a release-train model borrowed from Kubernetes itself. Under this approach, any feature that is complete by the feature-freeze deadline ships in the release, rather than being held back to line up with individual milestones. The dev.to post notes this is the first Gateway API release produced under that model.

What graduated to GA in v1.5

Per the post, six features moved into the Standard Channel — the API's generally available tier — with v1.5. Among the ones it details:

ListenerSet decouples listener definitions from the Gateway object. Previously, every listener had to be declared directly inside the Gateway; with ListenerSet, listeners live in separate objects and are merged onto a Gateway. The post points to multi-tenant environments as the main use case, since platform teams and application teams can each own different listeners. It also makes more than 64 listeners per Gateway possible, lifting an earlier constraint.

TLSRoute provides route-level TLS forwarding with no HTTP awareness. That makes it a fit for traffic such as database connections or message queues — workloads that need TLS handling but are not HTTP-based.

The HTTPRoute CORS filter brings native CORS configuration into the route itself, replacing the implementation-specific annotations that Ingress controllers have traditionally required for cross-origin policy.

Client certificate validation and certificate selection round out the highlighted set with more advanced TLS controls for connections terminated at the Gateway.

The migration clock

The sequencing is the real story. The GA release landed in late February and Ingress-NGINX is set to wind down in March. The dev.to author presents this timing as favorable for migration, since the standardized, generally available capabilities teams need — particularly replacements for controller-specific annotation workarounds such as CORS — are in place as the old controller exits.

For teams still running classic Ingress manifests, the post positions 2026 as the year to execute a migration rather than simply evaluate one.

Why it matters

Ingress-NGINX's retirement converts Gateway API adoption from a nice-to-have into scheduled work. Any cluster depending on the controller now needs a concrete migration path, and the annotation-driven behavior that classic Ingress normalized — CORS handling being a clear example — has to be re-expressed in native API terms.

The specific features in v1.5 also signal who the API is built for. ListenerSet addresses the organizational reality of shared platforms, where a central team owns the Gateway and many teams attach their own listeners — a pattern the original Ingress design accommodated poorly. TLSRoute extends the API's reach beyond HTTP workloads, and the client-certificate work hardens TLS termination at the edge.

Finally, the shift to a release-train cadence says something about predictability: features land on a fixed schedule when they are ready, much like Kubernetes itself. For teams planning a move off Ingress-NGINX, that regularity — combined with two consecutive major releases — is the context the dev.to post argues makes 2026 the right moment to complete the switch.