Gateway API vs Ingress Controllers: The Future of Kubernetes Traffic Management
As more traffic is flowing to, and from, a Kubernetes cluster ranging from customers/clients interacting with an application (like a web UI) or outbound calls to parts of the application stack that are needed for functionality (like a database), the ability to provide a proper means for north/south (ingress/egress) traffic is essential for any cloud-native networking stack.
It's the difference between understanding how traffic flows through/to an application and what calls are made to said stack.
In this blog post, you'll learn the key differences between Kubernetes Gateway API and Ingress, along with the for implementation.
Why The Need For Either?
When thinking about the need for proper traffic management to (ingress) and from (egress) your cluster, let's take a moment to think about how applications used to work (and still do in some legacy environments) from a monolithic perspective.
With a monolithic application stack, everything was contained within a single environment. That could be one server or set of servers in High Availability (HA), which typically looks like one server on (hot) and one or more servers off (cold), ready to ingest traffic if the one server that's "hot" malfunctions for any reason. With this style of application stack, everything ran under one roof, from the frontend to the backend, and possibly even the database. This made ingress traffic pretty easy because all of the services were under one roof.
With microservices, that narrative is a bit different.
Microservices/decoupled applications are split up into various services.
Because of that, some of the decoupled applications need a way to communicate outside of the cluster (for example, connecting to a database) and a way to have outside parties communicate with them (for example, someone accessing your public-facing application).
What's The Difference Between The Two?
You may be thinking to yourself "We already spent all of this time implementing an Ingress controller" or "they're both doing the same thing, it seems, so what's the difference?".
There are three differences:
- Agnostic
- Advanced routing
- Protocol support
Kubernetes Gateway API is vendor-agnostic. You're not tied into a specific implementation from a particular vendor. It's far more "Kubernetes native" as it ships within the networking Named API Group.
Kubernetes Gateway API has:
- Header-based routing
- Query parameter matching
- HTTP method matching
- Weight-based traffic splitting
- Request/response modification
And lastly, in terms of protocols, Ingress Controllers support HTTP and HTTPS. Kubernetes Gateway API supports HTTP, HTTPS, gRPC, TCP, and UDP.
You can think of Kubernetes Gateway API like Ingress 2.0.
Should You Migrate?
If you're already using an Ingress Controller and it's fully implemented, you should only migrate if you need:
- Traffic splitting (e.g - canary deployments).
- Cross-namespace routing.
- Protocol support beyond HTTP and HTTPS.
- You have multi-team environments.
- You want to be vendor agnostic.
- Need better RBAC separation
And overall, if you need advanced-level routing capabilities, which the majority of organizations handling several decoupled apps do.
The good news is that the Nginx Ingress Controller supports the Kubernetes Gateway API, Traefik (another popular Ingress Controller) supports the Kubernetes Gateway API, along with Envoy Gateway and Gloo Gateway. Because of that, the migration path is pretty straightforward.
Conclusion
There isn't specific information out there that's stating "All Ingress Controllers are going away", but it's safe to say that the Kubernetes maintainers are making an effort to bring Ingress "in-house" by creating a native solution that's more sophisticated than the standard Ingress Controllers we know today.
If you'd like to learn how to implement a Kubernetes Gateway API, you can check out my other blog post here: https://www.cloudnativedeepdive.com/implementing-your-first-kubernetes-gateway-api/
Comments ()