Image Credit: Getty Images

No doubt the new Kubernetes excitement is the Gateway API. One of the more significant changes in the Kubernetes project, the Gateway API is sorely needed. More granular and 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 that infrastructure. The Gateway API is designed for those tasks. Once fully matured, it will help developers, SREs, platform teams, architects and CTOs by making Kubernetes infrastructure tooling and governance more modular and less bespoke.

But let’s be sure the hype does not get ahead of today’s needs.

The past and future Kubernetes gateway API

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

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

Today, most IT organizations are still either in the early adoption or the testing stage with Kubernetes. For many, just getting comfortable with the new architecture, networking constructs, and application and service management requirements requires considerable internal education and digestion.

Gateway API and Ingress controllers are not mutually exclusive

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

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

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

We are also hopeful that some of our new work around the Gateway API is taken back into the open-source community. We have been present in the Kubernetes community for quite some time and are increasing our open-source efforts around the Gateway API.

It could be interpreted that the evolving API provides an invaluable insertion point and opportunity for a “do-over” on service networking. But that does not mean that everyone is quick to toss out years of investment in other projects. Ingress will continue to be important as Gateway API matures and develops, and the two are not mutually exclusive.

Plan for a hybrid future

Does it sound like we think the Kubernetes world should have its Gateway API cake and eat its Ingress controller too? Well, we do. Guilty as charged. Bottom line: We believe Kubernetes is a big tent with plenty of room for both new constructs and older categories. Improving on existing Ingress controllers —which were tethered to a limited annotation capability that induced complexity and reduced modularity — remains critical for organizations for the foreseeable future.

Yes, the Gateway API 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 nor a silver bullet. Smart teams are planning for this hybrid future, learning about the improvements the Gateway API will bring while continuing to plan around ongoing Ingress controller improvement. The beauty of this hybrid reality is that everyone can run clusters in the way they know and desire. Every team gets what they want and need.

Brian Ehlert is director of product management at NGINX.