Kubernetes Gateway API: The Successor to Ingress
The Gateway API replaces Kubernetes Ingress with a role-oriented model, separating infrastructure from application routing. Use it when different teams need to manage their own traffic rules.
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.
Interview question
Under which circumstance would the Kubernetes Gateway API be the most appropriate choice over the standard Ingress API?
- a.If the goal is to avoid installing any custom resource definitions or controllers in the cluster.
- b.To simplify exposing a single HTTP service in a small, single-team cluster.
- c.When different application teams require self-service control over their routing rules on shared infrastructure.Correct
- d.For basic HTTP/HTTPS traffic management when advanced features like gRPC or TCP routing are not needed.
Why? this is the answer
The Gateway API is designed for complex, multi-tenant environments where platform administrators delegate routing control to application teams, as described in option C. Option B describes a scenario where Ingress would be simpler and sufficient. Option A is incorrect because Gateway API relies on CRDs and requires a controller. Option D describes a basic use case that Ingress can handle, while Gateway API's strength lies in its role-oriented model and support for advanced features beyond basic HTTP/HTTPS.
Just read this? Test yourself on what you have been reading.
Read the original → github.com
- #kubernetes
- #networking
- #ingress
- #api
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles