The Kubernetes world is experiencing a seismic shift as it moves from Ingress controllers to the shiny new Gateway API. While changing anything that works can be a challenge, it is beneficial for you to familiarize yourself with Gateway API.
What are the pros and cons of sticking with a reliable Ingress controller like NGINX Ingress Controller versus moving to the more complex and powerful Gateway API? Let’s examine potential new challenges in managing traffic across the networking boundary, the evolution from Ingress to Gateway API, and why our implementation of the Gateway API – NGINX Gateway Fabric – is worth the added complexity.
The Classic Choice, Ingress Controllers
For years, Kubernetes has relied on Ingress controllers to handle external (north-south) traffic flowing into the cluster. The Ingress model is simple. It translates your Ingress rules into configurations that a proxy can understand and execute.
NGINX Ingress Controller is fast, reliable, and excels at HTTP/HTTPS routing, SSL termination, and basic load balancing. Write a bit of YAML, maybe a few annotations, and traffic is flowing smoothly to your services.
But Ingress has its limits. It was designed for a simpler time in Kubernetes’ history. It struggles with advanced traffic management needs like canary releases or blue-green deployments. And annotations can pile up, creating a tangled web that makes portability a headache. As Kubernetes matured into a platform for sprawling microservices and complex apps, Ingress has started to limit progress.
Enter the Future with the Gateway API
Kubernetes’ modern answer to Ingress’s limitations is the Gateway API. This isn’t just a minor upgrade; it’s a complete reimagining of how networking should work in Kubernetes. The Gateway API hit v1.0 in late 2023 and has been gaining momentum ever since. It’s designed to tackle Ingress’s shortcomings head-on with a more flexible, extensible, and powerful framework.
The Gateway API introduces a modular structure with distinct roles – infrastructure provider, cluster operator, and app developer – and new resources like GatewayClass, Gateway, and HTTPRoute. Unlike Ingress, it’s protocol-agnostic, supporting HTTP, TCP, gRPC, and more. It handles both north-south and east-west traffic while offering built-in support for techniques like blue-green or canary deployments. No more annotation overload since the Gateway API puts these capabilities into its specifications, making your configurations cleaner and more portable.
In fact, the Kubernetes community focused on the networking needs and identified three components that needed focus:
- Role-oriented design (Route versus Gateway)
- Expression (standardizing common policies into the API)
- Extensibility (enabling extensions of the Gateway API for custom functionality, filters, and policies)
NGINX embraced the shift in Kubernetes networking with NGINX Gateway Fabric, our implementation of the Gateway API. Built with NGINX as the data plane, it’s a forward-thinking option that promises the same high performance NGINX is known for, combined with the Gateway API’s cutting-edge features.
Reasons to Make the Switch
So, why would anyone trade the simplicity of an Ingress controller for the complexity of the Gateway API? It comes with a steeper learning curve, more resources to manage, and new concepts to understand. If your Ingress controller is doing the job today, switching might feel like overcomplicating a successful setup.
But here’s the thing: with complexity comes power. If your use case is straightforward (routing HTTP traffic to a handful of services), Ingress and NGINX Ingress Controller are still a great fit. However, if your needs are more advanced, the Gateway API starts to look like the better option.
Let’s break down some of the scenarios where the Gateway API excels:
- Advanced deployments – Need traffic splitting for blue-green or canary rollouts? The Gateway API has it built in, no annotation hacks required.
- Future-proofing – Ingress development within the community has shifted to the Gateway API. Adopting it now positions you for long-term success.
- Diverse traffic types – If you’re working with HTTP, TCP, gRPC, or other protocols, the Gateway API handles them with ease.
- East-west traffic management – Pair the Gateway API with a service mesh, and you’ve got a unified way to control traffic across your entire cluster.
Why NGINX Gateway Fabric?
NGINX Gateway Fabric combines NGINX’s proven strengths like performance, stability, reliability and innovation, with the capabilities of the Gateway API. NGINX Gateway Fabric isn’t just about solving today’s problems – it prepares you for a future where Kubernetes networking is anything but simple. If your applications are growing, spanning across multiple namespaces, or requiring zero-downtime deployments, the NGINX Gateway Fabric’s complexity starts to feel like a worthwhile investment.
Unlike other options, NGINX Gateway Fabric also offers a single interface, with everything built around the Gateway API. This means less configuration mess, less worry about keeping versions in lockstep, and clear delivery of your underlying intent.
Additionally, NGINX’s team is fully committed to this transition. NGINX Ingress Controller isn’t going away for a while, but NGINX Gateway Fabric is our bridge to the next generation of Kubernetes networking. It’s a chance to leverage NGINX’s performance pedigree while embracing a standard that’s set to become the default for Kubernetes traffic management.
To learn more, read the blog post 5 Things to Know About NGINX Gateway Fabric.
The Big Question: Is the Move Worth It for You?
The choice between sticking with NGINX Ingress Controller and adopting the Gateway API via NGINX Gateway Fabric comes down to your team’s specific needs. If you’re a small team with a simple app and no planned major changes, NGINX Ingress Controller might still be the best fit. (However, keep in mind that all work on Kubernetes Ingress has been frozen.)
But if you’re building for scale or running into limitations like clusters shared among teams, or want role-oriented design, then NGINX Gateway Fabric is the smarter long-term choice.
The transition might be challenging, but the payoff is a networking solution that’s ready for Kubernetes’ future. So, think about this: What’s your team’s biggest networking challenge right now? That’s the key to deciding if NGINX Gateway Fabric is juice worth the squeeze.
Let us know your thoughts on the new NGINX Community Forum – we’d love to learn how you’re tackling Kubernetes networking!