Kubernetes Gateway API Reality Check: Ingress Controller is Still Needed

Without a doubt, the new excitement of Kubernetes is the API Gateway. One of the biggest changes in the Kubernetes project, the API Gateway is badly needed. Finer and more robust control over Kubernetes service networking better addresses the growing number of use cases and roles within the cloud-native paradigm.

Shared architecture – at all scales – requires flexible, scalable and extensible means to manage, observe and secure this infrastructure. The API Gateway is designed for these tasks. When mature, it will help developers, SREs, platform teams, architects, and CTOs by making Kubernetes infrastructure tools and governance more modular and less bespoke.

But let’s make sure the hype doesn’t preempt today’s needs.

The Past and Future Kubernetes Gateway API

There remains a gap between the current and future states of Ingress control in Kubernetes. This has led to a common misconception that the API Gateway will replace the Kubernetes Ingress Controller (KIC) in the short term or make it less useful in the long term. This view is incorrect for several reasons.

Ingress controllers are now built into the functional architecture of most Kubernetes deployments. They have become de facto. At some point, the API Gateway will be mature enough to replace all Ingress API functionality and even the implementation-specific annotations and custom resources that many Ingress implementations use, but that day remains a long way off.

Today, most IT organizations are still in the early adoption or testing phase with Kubernetes. For many, simply getting to grips with the new architecture, networking constructs, and application and service management requirements requires considerable internal training and digestion.

Gateway API and Ingress Controllers are not mutually exclusive

As we have done at NGINX, other Ingress maintainers will likely implement the API Gateway in their products to take advantage of the new functionality and stay current with the API and the Kubernetes project. Just as RESTful APIs are useful for many tasks, the Kubernetes API underpins many products and services, all built on top of its powerful container orchestration engine.

The API Gateway is designed to be a universal component layer for managing service connectivity and behaviors within Kubernetes. It’s expressive and extensible, making it useful for many roles, from DevOps to security to NetOps.

As a team that invested considerable resources in an open-source Ingress controller, NGINX could have chosen to integrate the API Gateway into our existing work. Instead, we chose to leverage API Gateway as a standalone, more open project. We went this route so as not to project the existing constraints of our Ingress Controller implementation onto the ways we might hope to use the Gateway or NGINX API in the future. With fewer constraints, it’s easier to fail faster or explore new designs and concepts. Like most cloud-native technologies, the API Gateway’s build is designed for loose coupling and modularity – even more so than the Ingress Controller, in fact.

We also hope that some of our new work around the API Gateway will be picked up in the open source community. We have been in the Kubernetes community for some time and are increasing our open source efforts around the API Gateway.

One could interpret that the evolution of the API provides an invaluable entry point and opportunity for a “redesign” on service networking. But that doesn’t mean everyone is quick to throw years of investment into other projects. Ingress will continue to be important as the API Gateway matures and grows, and the two are not mutually exclusive.

Plan for a hybrid future

Do we think the Kubernetes world should have its API Gateway cake and also eat its Ingress controller? Well, we do. Guilty as charged. Conclusion: We think Kubernetes is a big tent with plenty of room for new builds and older categories. Improving existing Ingress controllers, which were tied to limited annotation capability that resulted in complexity and reduced modularity, remains essential for organizations for the foreseeable future.

Yes, the API Gateway will help us improve Ingress controllers and unleash innovation, but it’s an API, not a product category. This new API is not a magic wand or a silver bullet. Smart teams are planning for this hybrid future, learning about the improvements the API Gateway will bring while continuing to plan around the continuous improvement of the Ingress controller. The beauty of this hybrid reality is that everyone can manage clusters as they know and want. Each team gets what it wants and what it needs.

Brian Ehlert is Director of Product Management at NGINX.