Gateway API 1.5: Kubernetes Networking Reaches the Next Level

📷 "Docker HQ, San Francisco, California" by willbuckner is licensed under CC BY 2.0. To view a copy of this license, visit https://creativecommons.org/licenses/by/2.0/.

In February 2026, the Kubernetes SIG Network released version 1.5 of the Gateway API – the largest and most significant version of the project to date. Six key features that were previously only available in the experimental channel are now stable in the standard channel. For teams running Kubernetes networking at production level, this release is a milestone: it marks the transition of the Gateway API from a promising alternative to a serious successor to the classic Ingress.

What is the Gateway API?

The Gateway API is the successor to the Kubernetes Ingress resource type and addresses its long-standing weaknesses: limited routing capabilities, lack of multi-tenancy support, and dependence on proprietary annotations. Gateway API introduces specialized roles – Infrastructure Provider, Cluster Operator, and Application Developer – thus better reflecting real team structures. Version 1.5 now brings six long-awaited features to the stable standard channel.

ListenerSet: Multi-tenant gateways become reality

Arguably the most important addition is ListenerSet (GEP-1713). Previously, all listeners had to be defined directly in the Gateway object – a single point of control that is especially painful in multi-tenant environments. Every team that needed its own hostname or TLS certificate was dependent on the platform team.

ListenerSet fundamentally changes this: Listeners can be defined independently of the Gateway in separate namespaces and attached to a central Gateway via parentRef. The Gateway controller automatically merges the listeners of all referenced ListenerSets. Platform teams own the Gateway, application teams manage their own listeners in their namespace – including their own TLS certificates. The previous limit of 64 listeners per Gateway is now effectively removed.

A concrete example: A central Gateway in the infra namespace with an HTTP listener on port 80. Two teams each define a ListenerSet in their namespaces (team-a, team-b) with their own HTTPS listeners and certificates. The Gateway controller merges all three – one load balancer, multiple teams, no Ingress controller sprawl.

TLSRoute becomes stable

TLSRoute is now available in the standard channel as v1 after years in the experimental phase. It allows routing of TLS connections based on the SNI (Server Name Indication) field of the TLS handshake – i.e., even before the actual application connection is established.

Two operating modes are available: Passthrough – the data stream is passed through encrypted to the backend, ideal for strict security requirements and end-to-end encryption. Terminate – the gateway decrypts the TLS data stream and forwards it as plaintext to the backend, necessary when the gateway itself needs to set HTTP headers or make routing decisions.

Important for existing users: Those upgrading from Gateway API v1.4 or earlier in the experimental channel to v1.5 standard must migrate their existing TLSRoutes, as these are stored in older API versions (v1alpha2/v1alpha3).

Overview of other stable features

In addition to ListenerSet and TLSRoute, four other features have moved to the standard channel:

HTTPRoute CORS Filter – server-side CORS configuration directly in the route, without middleware or annotations.
Client Certificate Validation – mutual TLS authentication (mTLS) between client and gateway.
Certificate Selection for Gateway TLS Origination – selection of the certificate with which the gateway authenticates to the backend.
ReferenceGrant – promoted to v1 after more than a year without changes, thus falling under the GA API contract (no more breaking changes).

New release structure

With v1.5, the Gateway API switches to a release train model. Instead of releasing individual features independently, there are fixed milestones at which all completed features are published together. The model is Kubernetes’ own release process, overseen by SIG Release. The newly introduced roles of Release Manager and Release Shadows are intended to further improve coordination and release quality.

Good news for operators: The Gateway API is not tied to a specific Kubernetes version. From Kubernetes 1.30 onward, the latest version can be installed without updating the cluster. At this point, seven implementations are already fully conformant with Gateway API v1.5, including Envoy Gateway, Cilium, Istio, and Contour.

Conclusion

Gateway API v1.5 is a quantum leap for Kubernetes networking. With ListenerSet and TLSRoute in the stable standard channel, the API addresses the two biggest criticisms of classic Ingress: lack of multi-tenancy capabilities and insufficient TLS routing options. Additionally, the timing is right: with the discontinuation of Ingress-NGINX at the end of March 2026, many teams are losing their default Ingress controller – switching to the Gateway API is not only technically sound but is becoming inevitable for more and more production environments. Anyone running Kubernetes should have Gateway API v1.5 on their radar and begin planning their migration.

Sources

🌐 Machine-translated from the German original, editorially reviewed. 🤖 Written with AI assistance.