Gateway API v1.5: Moving features to Stable

The Kubernetes ecosystem just got a significant stability boost. On March 14, 2026, the Kubernetes SIG Network community released Gateway API v1.5—a milestone release that graduates several experimental features into stable, production-ready status. If you’re running Kubernetes clusters and managing ingress traffic, this is worth paying attention to. Gateway API represents the next generation of how Kubernetes handles north-south traffic (traffic entering and leaving your cluster), moving beyond the older Ingress API with a more flexible, role-based design.

So what exactly is Gateway API, and why does this stability matter? At its core, Gateway API is a set of custom resource definitions (CRDs) that give you more expressive control over how external traffic reaches your services. Instead of the flat, somewhat rigid Ingress model, Gateway API introduces a layered approach: a Gateway resource handles the actual infrastructure (like a load balancer or reverse proxy), while Route resources (like HTTPRoute and TCPRoute) define how traffic should be directed to your backend services. This separation of concerns means infrastructure teams and application teams can work more independently. The move from Experimental to Standard in v1.5 means these APIs have undergone extensive testing, the community has reached consensus on their design, and you can depend on backward compatibility going forward—critical for any production workload.

From a practical standpoint, this release opens doors for more sophisticated traffic management scenarios. Consider a multi-tenant SaaS platform where different customers need different routing rules, or an organization running canary deployments that require precise traffic splitting. With stable Gateway API features, you can now implement these patterns with confidence that the API won’t change underneath you. You might define an HTTPRoute that splits 90% of traffic to your current service version and 10% to a new one, all while keeping that logic separate from your infrastructure configuration. The role-based design also means a platform team can provision a Gateway, while application teams simply declare their own Routes—no need for shared access to cluster-wide resources.

The graduation of these features from Experimental to Standard is exactly what you want to see in a maturing technology. It signals that Gateway API is ready for broader adoption, that the community has worked through the tough design questions, and that you can build production systems on top of it without worrying about breaking changes. If you’ve been holding off on Gateway API while it was in flux, v1.5 is a good moment to revisit it. Start by checking whether your infrastructure provider supports it, then experiment with it on a non-critical cluster. The investment in learning Gateway API now will pay dividends as it becomes the standard way to handle ingress across the Kubernetes ecosystem.