Kubernetes Gateway API: The Successor to Ingress

WHY IT EXISTS The standard Kubernetes Ingress API is a single resource that mixes infrastructure concerns (like which load balancer to use) with application routing rules. This becomes a bottleneck in large, multi-tenant clusters, as a single Ingress resource is not expressive or secure enough to manage complex traffic patterns across different teams.

THE MENTAL MODEL The Gateway API decouples these concerns using a role-based model. Think of it like an airport. An infrastructure team acts as the airport authority, defining what types of gateways are available (GatewayClass) and provisioning the actual load balancer infrastructure (Gateway). Application developers then act like airlines, defining their own routing rules (HTTPRoute, TCPRoute) to direct traffic to their services, without needing to manage the underlying infrastructure.

HOW IT WORKS The API is a collection of Custom Resource Definitions (CRDs) that work together. The key resources are: GatewayClass (a template for Gateways), Gateway (a request for a load balancer, specifying listeners), and various Route resources (HTTPRoute, GRPCRoute, TCPRoute, UDPRoute). App developers create Route objects that attach to a Gateway, which then implements the routing logic. This separation allows platform admins to control infrastructure while developers manage their application traffic.

WHEN TO USE IT Use the Gateway API for complex routing scenarios in multi-tenant Kubernetes clusters. It is ideal when you need to delegate routing control to application teams in a secure, self-service manner. It is also the standard for advanced features like traffic splitting, header-based routing, and native support for protocols beyond HTTP, such as gRPC, TCP, and UDP.

WHEN NOT TO USE IT For simple applications in a single-tenant cluster where one team manages everything, the standard Ingress resource may be sufficient and less complex to set up. The Gateway API requires a controller to be installed in the cluster (e.g., from a service mesh or cloud provider), so it's not usable out-of-the-box on a bare cluster.

ONE CANONICAL EXAMPLE A platform team creates a Gateway resource that provisions a cloud load balancer on ports 80 and 443. An application team can then create an HTTPRoute in their own namespace to claim the hostname store.example.com on that Gateway and route traffic to their products-api service. The app team never needs permissions to modify the cluster-wide load balancer itself.