Why Migrate from Kubernetes Ingress to Kubernetes Gateway?
The Kubernetes Ingress API has long been a reliable tool for configuring Ingress Controllers, allowing us to direct external traffic to our Kubernetes
Erica Hughberg 
The Kubernetes Ingress API has long been a reliable tool for configuring Ingress Controllers, allowing us to direct external traffic to our Kubernetes-hosted services using straightforward routing rules.
However, even the most common use cases, such as blue/green releases, require more sophisticated routing rules and configuration management than the Ingress API natively provides.
To address typical needs for traffic management and for separation of control of configuration cloud-natively a fundamental shift in how we think about configuring and managing the configurations was necessary.
Therefore the Gateway API by design, in contrast to the Ingress API, offers a more advanced and flexible tool for managing ingress traffic and its configurations.
Do I Really Need to Adopt the New Gateway API?
While useful, the Ingress API does not natively handle complex configurations. Many have relied on cumbersome, non-portable vendor extensions to handle everyday challenges.
Thankfully, those days are over. The Kubernetes Gateway API eliminates the need for many extensions, offering a robust, standardized approach to managing ingress traffic.
Moving to a solution that implements the Gateway API is not just about keeping up and adopting another standard or best practice; it’s about equipping yourself with a more advanced and flexible tool, empowering you to handle complex routing decisions and manage ingress traffic more efficiently.
I’m sure I’m not alone in echoing the saying, “don’t fix what isn’t broken” to help myself focus on investing in change that matters. How do you know if “not broken” isn’t good enough anymore? I have tried to distill down five motivations for adopting to the Gateway API, which include the need for more advanced routing features, support for multiple protocols, scalability, better isolation mechanisms, and alignment with the direction of Kubernetes and Open Standards.
Five Reasons to Migrate to Gateway API
1. You need to make complex traffic routing decisions
For instance, the Ingress API was designed for basic HTTP routing, but modern applications often require more sophisticated traffic management strategies. The Gateway API, in contrast, supports advanced routing features such as header-based routing and weighted routing for canary releases, which are only possible with the Ingress API through vendor-specific extensions.
With ingress controllers, you must adopt non-portable vendor-specific configurations to manage more complex traffic routing decisions. The Gateway API supports such advanced configuration in a unified, vendor-neutral way.
2. You need to support more than HTTP(S) traffic
The Gateway API supports route configurations for multiple protocols (HTTP, HTTPS, gRPC, TCP, UDP, etc.) beyond the HTTP(S) capabilities of traditional Ingress.
Similarly to point 1, handling other protocols with Ingress controllers requires vendor extensions, ultimately leading to vendor lock-in and non-portable configurations. The Gateway API defines this, so you now have portable configurations that work across multiple solutions.
3. You want a scalable resource-efficient ingress solution
Kubernetes Gateway Controllers, which implement the Gateway API, are generally more scalable than Ingress controllers due to the decoupling of the control plane, which handles management tasks, and the data plane, which handles traffic routing.
This separation allows the data plane to scale based on traffic demands without being bogged down by control plane activities. Similarly, the control plane can operate and update configurations without directly impacting traffic flow.
For most Ingress controllers, the control and data planes have been coupled, which leads to coupled scaling of pods as either client traffic or management traffic loads increase.
4. You want to have more than one team share a Kubernetes cluster safely
The Gateway API introduces better mechanisms for isolation of change between different tenants in the cluster, enhancing stability and making Kubernetes deployments safer.
For example, with the Gateway API, you can have a shared gateway for the cluster, and dedicated namespace-bound HTTPRoutes can be attached to the shared Gateway. With resources like the Gateway and Routes segregated, you can apply specific rules for how their configurations are managed.
Granular configuration control is crucial for organizations with multiple teams operating in a single Kubernetes cluster. The Gateway API’s design enables segregation and finer-grained control that wasn’t possible with the flatter Ingress API.
5. You want to align with the direction of Kubernetes and open standards
The Gateway API is not just a new standard but an evolving one with active community support and continuous development. It is designed to keep pace with the ever-changing tech landscape, making it a reliable and future-proof solution for handling ingress traffic to Kubernetes, ensuring your traffic management solution is always up to date and in line with the latest features in the Kubernetes ecosystem.
Organizations can ensure that their traffic management solution enables them to adopt best practices and the latest features in the Kubernetes ecosystem by adopting solutions that implement the Kubernetes Gateway API.
Erica Hughberg 
