If you’ve been under a rock, it’s possible you missed the noise about the Gateway API. But probably not – it’s been a loud, major topic discussed in the Kubernetes community. And with good reason!
The Gateway API is not just another set of Kubernetes API resources – it’s a significant shift in the landscape of cloud-native technologies. By redefining how networking and communications are handled in Kubernetes, the Gateway API aims to set the course for the future of cloud-native networking.
As its adoption begins, we find ourselves at a critical juncture. Specifically, should an implementation of the Gateway API serve multiple API surfaces (in particular, the Ingress API and existing service mesh APIs)? Or will users be better served by products that are solely focused on the Gateway API (and its collection of resources) with a clean break from the past? This will be a crucial product decision with implications far into the future. Each approach has its merits and drawbacks. Let’s consider them.
Extending an Existing Solution with the Gateway API
Mapping the Gateway API back onto previous API surfaces in existing products delivers a smoother on-ramp for developers and Platform Ops teams. It can allow for a more gradual approach to shifts in DevOps, networking, and developer experience.
Here are the primary benefits of embedding:
- Easier Deployment and Implementation – One of the major advantages of embedding the Gateway API into existing Kubernetes Ingress systems and mapping it back onto an existing API surface is that it generally requires less new implementation and deployment for service owners and application teams. On their end, not much changes except the tools they have formerly used get a nifty upgrade by leveraging the benefits of the Gateway API.
- Consistent Monitoring and Operations – When combined with existing Ingress controllers, the Gateway API and attached resources can be monitored and operated from the same console or operations dashboard that applies to existing service networking systems. This unification simplifies how we handle networking resources as administrators can control and monitor all networking elements (both old and new) from a single source. This is not just convenient – it boosts operational efficiency. It can also improve security by making it easier to spot anomalies without forcing security teams to watch yet another set of metrics on their already busy dashboards.
- Leverages Existing Extensions and CRDs – For organizations that have already invested in customizing or extending their Ingress controllers, extensions can often be adapted to work with the Gateway API. This means that the time and effort spent on creating Custom Resource Definitions (CRDs) may not go to waste and could offer a more robust networking solution when combined with the Gateway API.
Choosing a Dedicated Gateway API Implementation
The Gateway API is designed to make the overall architecture, operating services, and applications in Kubernetes more user friendly and easier to manage. Clearly defined standardization of service networking is intended to enhance interoperability between Kubernetes services and products, and to reduce vendor lock-in.
Let’s look at the key advantages of a dedicated approach and compare it to potential downsides of a combined implementation.
Less Complexity
While adding new features to existing systems is beneficial, it also introduces complexity. Integrating the Gateway API into existing systems would mean that every new Ingress controller setup needs coordinated migration between the existing controllers, Ingress-oriented CRDs, and the new API features. This can make the setup process cumbersome and error-prone, slowing down development cycles and requiring additional testing before true production deployment. You can also expect to see a lot more edge cases resulting from unforeseen conflicts or scenarios.
A dedicated, standalone Gateway API implementation would avoid all these challenges and dramatically decrease complexity. Over time, this would result in reduced operational overhead, improved security, and easier performance tuning and troubleshooting.
Fewer Migration Headaches
For both the Ingress controller and Gateway API, a single hostname cannot be supported by two distinctly different API models at the same time. The cost of managing conflicts is too high. This means users will have to choose one API model or the other for their applications. Customers will inevitably have to migrate application by application over to the new API to take advantage of outage windows and planned downtime.
This is a big reason why trying to support, maintain, and secure two API surfaces within a single implementation does not appear to carry high value for the customer in the end. It is better to give them a strong tool that is built around the API model and patterns. And that tool should be the Gateway API, because it’s the future direction of Kubernetes.
Smaller Footprint and Fewer Resources
The Gateway API was designed not only to standardize but also to shrink the footprint of service networking, eliminating the need for new core CRDs and other customizations that were previously necessary to cover fundamental gaps left by the Ingress API.
As a standalone component, the Gateway API will therefore require less compute capacity and can run more easily in constrained environments. That translates to fewer infrastructure resources required to manage service networking, which can be particularly important in applications that are resource intensive and deal with high volumes of data and traffic.
Security Policies and RBACs
A standalone Gateway API implementation allows for tighter security by default. Ingress resources under the previous API regime did not natively support security policies. Also, role-based access controls (RBACs) needed to be coarsely defined because the Ingress resource cannot be granularly managed through RBAC which led to one of the major reasons for introducing the Gateway API in the first place.
In a dedicated Gateway API implementation, RBACs and security policies are much easier to create, and the overall architecture is less complex. In short, they are first-class citizens rather than added functionality.
Default Separation of Concerns
The Gateway API is designed to create a separation of concerns between platform owner and service owner. Gateways represent network-level service management. Routes represent application or microservices-level management. So, a cluster operator can modify the Gateway API and make changes for the entire gateway while a service owner can define routing rules and traffic management for their service or application without having to coordinate with platform administrators.
This is a clean separation of concerns. Meanwhile, the Ingress API was not really designed with multiple roles in mind, making it more challenging. If using a combined implementation, the Gateway API already accommodates the more convoluted mechanism that is required to create a separation of concerns in the Ingress API model.
Less Vendor Lock-In, More Interoperability
The Gateway API specification was engineered with interoperability in mind. Therefore, it is enforced through closely defined and expressive standards. This translates to a reduced chance for total vendor lock-in because it is much easier to port Kubernetes service architectures (and even CRDs) from one Gateway API implementation to another, provided that the implementation is standalone and not tethered to other service networking APIs.
Conclusion: Dedicated Gateway API Wins
While our opinion is made, we invite you to come to your own conclusion in this debate. Based on our analysis of the two options, we believe that it makes more sense to future-proof Ingress and service networking by adopting dedicated Gateway API implementations, as we did with our NGINX Gateway Fabric project. This is not to say that implementing the Gateway API while continuing to support older Ingress paradigms is without merit. In the shorter term, a combined implementation might make life easier for service owners and platform teams by reducing some operational complexity and affording them greater continuity.
Over the longer term, however, the benefits of a standalone approach become more prominent: interoperability, security, cost, and reduced complexity. In addition, emergence of the Gateway API for Mesh Management and Administration (GAMMA) paves the road to provide unified app connectivity to, from, within, and across Kubernetes clusters with more features delivered through a single API surface. Kubernetes is complicated enough. There’s no reason to make it even more complicated. The Gateway API can go a long way towards simplifying and improving service networking in Kubernetes, particularly if we let it stand by itself.
If you are interested in getting involved in the NGINX’s implementation of Gateway API – whether by contributing, implementing, or testing – we encourage you to join our Gateway API-conformant NGINX Gateway Fabric project on GitHub.
++
Join us at KubeCon + CloudNativeCon North America this November 6 – 9 in Chicago for more on Kubernetes and the cloud native ecosystem.
##
ABOUT THE AUTHORS
Brian Ehlert, Director of Product Management, NGINX
Brian Ehlert is a Director of Product Management for NGINX, now a part of F5. He leads Kubernetes integrations including the NGINX Gateway Fabric for Gateway API and NGINX Ingress Controller projects from NGINX. Brian has worked in the technology sector for 25+ years across IT operations and product development, with experience in medical, retail, call center, mail order, and financial companies.
Matthew Yacobucci, Principal Software Engineer, F5
Matthew “Booch” Yacobucci is a principal software engineer at F5, where he focuses on Kubernetes solutions and other emerging technologies. He’s experienced in the distributed computing and networking industries with skills in Linux, Go, container orchestration systems, and concurrency patterns.
