What is the Kubernetes Gateway API?
The Kubernetes Gateway API is an official Kubernetes project for L4 and L7 routing. It defines how traffic enters a cluster and reaches Services, using separate resources for the gateway itself and for the routes that attach to it. It is the successor to Ingress, which is frozen and gets no new features.
Think of an office building. Facilities runs the front door and decides which floors are open, while each team puts up its own signs to its rooms. Gateway API splits traffic the same way: one team owns the entrance, other teams own the routes behind it.
Gateway API is not built into Kubernetes. Its kinds are custom resources, so you install the CRDs, and a controller from an implementation turns them into a working proxy or load balancer.
Which resources make up Gateway API?
GatewayClass
A GatewayClass is a cluster-wide template for gateways. It names the controller that handles them, much like a StorageClass names a provisioner.
Gateway
A Gateway is one entry point for traffic. It has listeners with a port, a protocol and an optional hostname, and it decides which routes may attach. By default it only accepts routes from its own namespace, and it can be opened to all namespaces or to ones matching a label.
Routes
Routes map traffic from a listener to backend Services. Each protocol has its own kind:
- HTTPRoute for HTTP and terminated HTTPS, matching on path, headers and other request data.
- GRPCRoute for gRPC, which needs HTTP/2 on the gateway.
- TLSRoute for TLS connections routed by SNI, either passed through or terminated.
- TCPRoute and UDPRoute for plain layer 4 forwarding, still in the experimental channel.
How is Gateway API different from Ingress?
Roles
An Ingress is one object that mixes the entry point with the routing rules. Gateway API splits them, so a platform team runs the Gateway and application teams manage their own routes in their own namespaces. Attaching needs both sides to agree: the route names the Gateway in its parentRefs, and the listener has to allow that route’s namespace and kind.
Features in the spec
With Ingress, header matching, traffic weights and similar features lived in controller-specific annotations that did not carry over between controllers. In Gateway API they are fields in the API. A canary release, for example, sets weights of 90 and 10 on two backends in one HTTPRoute rule.
Why it matters now
The community ingress-nginx controller was retired, and it has received no releases or security fixes since March 2026. The Ingress API itself stays, but any cluster still running that controller needs a replacement. Moving to a Gateway API implementation solves that and drops the annotations at the same time.
How enum handles Gateway API
enum Kubernetes Engine gives you L4 load balancers for TCP and UDP, and incoming traffic reaches the cluster only through them. There is no managed Ingress or Gateway controller, so you install the Gateway API CRDs and an implementation of your choice. Its proxy then runs behind a Service of type LoadBalancer.
FAQ
Is Ingress being removed from Kubernetes? No. The Ingress API is generally available, frozen and has no removal planned. Existing Ingress objects keep working with a maintained controller, but new routing features only go into Gateway API.
Do I need a service mesh to use Gateway API? No. Gateway API covers traffic entering the cluster on its own. The same route resources can also describe traffic between services in a mesh, but that is optional and needs a mesh implementation.
Can I run Ingress and Gateway API in the same cluster? Yes. They are separate resources, handled by separate controllers, so you can move one hostname or application at a time. Keep both until every route is migrated and tested, then remove the Ingress objects.