Kubernetes is at the center of the cloud native world and a big part of the platform is networking, both inside the cloud and across clouds.

At the KubeCon NA 2023 conference this week, developers celebrated the general availability (GA) of the Gateway API, which literally opens up a new gateway to how Kubernetes networking and connectivity will be enabled in the future. Gateway API is intended to replace the  Ingress API, which has long been one of the primary ways that a cloud native environment gains access to services outside of a cluster. Gateway API aims to solve numerous shortcomings in Ingress API and already benefits from the broad participation of many  vendors.

The Gateway API in Kubernetes reached GA status after four years of development and feedback from the community. In a KubeCon session Rob Scott, staff software engineer for GKE Networking at Google and Nick Young, senior software engineer at Isovalent detailed the history of the Gateway API, what the 1.0 can do and where the project is headed.

Scott noted that the initial proposal for Gateway API was to not just be an Ingress v2, but rather the foundation for a next generation of service type load balancer, which is a goal that project has now hit.

As such a foundational component to cloud native technology, the Gateway API required broad participation. In fact, in Scott's view it was the most collaborative effort of any API project in Kubernetes.

The Gateway API benefitted from the contributions of over 170 developers. There are also over 30 organizations that have helped the project, including industry heavyweights Google, IBM, Microsoft, VMware, Hashicorp, Tetrate, Kong, Isovalent and Buoyant.

Beyond just contributions, organizations and vendors have already adopted the technology with Scott noting that there are well over 26 implementations of the API.

"If you have a networking implementation that you care about, chances are they already support Gateway API or they're working on it," Scott said.

In a data center, north/south connections are those in/out of a data center, while east/west are connections within a data center.

Young noted that over the last several years the Gateway API project engaged with early adopters to incorporate feedback and refine the API design. That feedback has led to a design where the Gateway API handles all the directions.

The project has also added support for enabling service mesh, which will profoundly rewrite the usability of cloud native service mesh technology in the coming years. For organizations looking to move from the existing Ingress API, there is now also a tool to help with the migration.

The 1.0 of the Gateway API is important as it means it's a stable API.

Young noted that the 1.0 signifies that the API is stable and will not change in a way that breaks any existing usage pattern for the foreseeable pattern. As such, users can feel confident upgrading existing applications and workloads that rely on the Gateway API knowing the interfaces will remain stable. Additionally, as a GA API in Kubernetes, it establishes the Gateway API as an integral and supported part of the Kubernetes networking ecosystem.

With the 1.0, the project is now transitioning from an experimental project to one focused on enhancements, improvements, and long-term support.

"After 1.0  you might say, well it's GA we must be done," Scott said. "No, we're just getting started, there's so much more ahead, we're trying to improve the UX, trying to improve the upgrade flow, but we also have so many more things in progress."