Kubernetes took the world by storm in 2014. A CLI-first experience, containers as a first-class citizen, and a need to dynamically scale workloads meant that Kubernetes was the right choice for many teams moving to the cloud. By late 2015, the community realized that there needed to be a standard way to manage traffic at the edge of a cluster and so the Ingress API was born.
The Ingress API remained under active development for almost five years before graduating to General Availability (GA) status in 2020. However, the Kubernetes Networking SIG were already thinking about the next big thing. The Ingress API was good for simple routing, but tools such as Kong Gateway were already surpassing its capabilities with advanced features such as request rewriting, plugins, and custom load balancing strategies.
The Gateway API was born at KubeCon San Diego in 2019, with the promise of being the next generation of routing configuration for Kubernetes. Kong’s very own Harry Bagdi was in the room when it all kicked off, and he was quick to share his excitement with the rest of the team.
That was four years ago, and through the work of a team of volunteers — which includes many Kong engineers — the Kubernetes Gateway API finally has a GA release. The Gateway API isn’t just a new front door into your cluster, it’s a whole house extension. It has official support for L4 traffic, policies to govern cross-namespace traffic, powerful route matching criteria, and more.
And those are just the technical benefits! From a business perspective, the Gateway API is a fundamental shift for API gateway vendors. It’s a shift back to open standards. It’s the ability to hire developers who know the Gateway API and can hit the ground running on day 1. It’s data portability through a shared configuration language that’s vendor-neutral. The Gateway API is good for the ecosystem, good for businesses, and good for users.
It took a village to get to this point. There are more than 20 active implementations of the Gateway API standard today. Contributors collaborated on mailing lists. They met on video calls. They pair-programmed on conformance test suites. The Gateway API is open source at its finest, and Kong is proud to have members of our team in multiple roles within the project.
The Gateway API may have been in development for four years, but we can assure you, we’re just getting started.
An API is only useful if people use it, and when your API is deployed on Kubernetes you need a way to expose it to your users. This is achieved with a Kubernetes Ingress that is exposed as a LoadBalancer service. There are plenty of Ingresses to choose from, across a variety of hardware and software-based options.
Kubernetes Ingresses are typically configured using the Ingress resource. As a built-in Kubernetes resource, Ingress has high adoption rates, but it’s not ubiquitous. Many vendors have chosen to build their own Ingress representations in order to overcome the limitations of the default Ingress resource.
At Kong, we chose to extend the default Ingress resource with annotations to augment the default routing rules of Ingress with powerful plugins such as authentication, rate limiting, and response caching. We also developed new resources such as TCPIngress and UDPIngress to address the fact that Ingress was only suitable for L7 traffic.
With the addition of the Gateway API, all of that goes away. The Gateway API takes the last four years of usage data by Kubernetes users and implements a new way to configure Kubernetes Ingresses that is flexible enough to allow for all of the use cases mentioned above. There are new TCPRoute and UDPRoute resources to allow for L4 traffic. You can use the extensionRef filter to customize the behavior of your API gateway. It’s all built into the Gateway API.
All of this functionality is supported by Kong Gateway, which is the most popular open source API gateway in the world, powering approximately 9 trillion API requests per month. Kong Ingress Controller pairs perfectly with the Gateway API, allowing you to access all the power of Kong Gateway using industry standard Kubernetes resources.
The Gateway API unlocks a whole new set of request routing capabilities. It’s driven innovation within Kong Gateway itself (such as the ability to match on query strings) and enables common use cases for end users such as weight-based traffic splitting.
Security is a big focus for the Gateway API GA release, with the capability to route traffic to services in different namespaces controlled using ReferenceGrant and allowedRoutes. This has been a long-standing pain point for Ingress API users, which is being well received by the community.
Finally, the Gateway API brings official support for L4 traffic. Many Kong Gateway users are proxying L4 traffic to pods running things like Kafka or MongoDB. The Gateway API provides an official way to define those traffic routes across all conformant Ingress implementations.
We’ll dive further into the technical aspects of the Gateway API in a future blog post from Mattia Lavacca, who’s a Gateway API contributor and KubeCon NA speaker (subscribe to make sure you don’t miss it).
The Gateway API fulfills the promise of open source. People from a variety of backgrounds collaborating to make the world a better place. Companies such as Google, Kong, VMware, and Isovalent coming together to build a vendor-neutral industry standard. Kong is the second biggest contributor to the Gateway API after Google, and given the disparity in company size we’re proud to have had such an outsized impact.
OSS is in Kong’s DNA, and the Gateway API has given us an opportunity to innovate in the Kubernetes ecosystem to drive open standards that benefit everyone, not just our customers.
The Gateway API project was born at KubeCon NA in San Diego 2019, we were in the room when the project kicked off. The team came back energized and started evangelizing internally about the opportunities the project provided.
As early adopters, Kong has helped define the requirements for Kubernetes Ingresses across the industry. We were the first conformance profile submitted upstream, and are 100% conformant with the GA release.
We’ve been involved with the Gateway API every step of the way. With Shane Utt as the networking SIG co-chair, Mattia Lavacca contributing to the conformance test suite and Mike Beaumont leading the charge for GAMMA, Kong have ensured that the future of Kubernetes Ingresses meets all our customers' needs.
Finally, we recognize that many users have years of configuration using the Ingress resource. To enable a smooth transition to Gateway API resources, we’ve contributed a Kong provider to ingress2gateway that migrates custom Kong annotations to Gateway API configuration objects. To learn more, see the ingress2gateway Kong provider.
The quickest way to get started with the Gateway API is using Kong Ingress Controller 3.0. We’ve revamped the KIC documentation to be Gateway API-first and built a brand new getting started guide using the HTTPRoute resource.
To learn more about the Gateway API and Kong, take a look at the following resources:
Managed Redis cache is a turnkey "Shared State" add-on for Kong Dedicated Cloud Gateways. It is designed to combine the performance of an in-memory data store with the simplicity of a SaaS product. When you spin up a Dedicated Cloud Gateway in Kong
With Kong Ingress Controller, when your Control Plane was hosted in Kong Konnect, and you were using Kubernetes Gateway API, your dataplane, routes, and services were in read-only mode. When using Kong Ingress Controller with Kubernetes Gateway API
Running Kong in front of your Solace Broker adds real benefits: Authentication & Access Control – protect your broker from unauthorized publishers. Validation & Transformation – enforce schemas, sanitize data, and map REST calls into event topics.
Architecture Overview A multicloud DCGW architecture typically contains three main layers. 1\. Konnect Control Plane The SaaS control plane manages configuration, plugins, and policies. All gateways connect securely to this layer. 2\. Dedicated C
The Shifting Economic Landscape: The AI token economy in 2026 is evolving, and enterprise leaders must distinguish between low-cost input tokens and high-premium output tokens to maintain profitability. Agentic AI Financial Risks: The transition t
Imagine 47 million requests hitting your platform last month. Can you prove who made each one—and invoice with confidence? If that question tightens your stomach, you're not alone. Metered billing for APIs promises fair, transparent pricing that s
Your Kafka Doesn't Have to Live Behind a Wall When teams resort to VPC peering or PrivateLink to expose Kafka, they're not solving the problem — they're managing it, one network topology decision at a time. Every new external consumer adds compl