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](http://git.k8s.io/community/sig-network)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](https://konghq.com/blog/engineering/gateway-api-vs-ingress)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](https://konghq.com/blog/product-releases/gateway-api#footer-newsletter:~:text=POWERING%20THE%20API%20WORLD)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](https://konghq.com/blog/engineering/gamma-and-kuma)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](https://kubernetes.io/blog/2023/10/25/introducing-ingress2gateway/)ingress2gateway that migrates custom Kong annotations to Gateway API configuration objects. To learn more, see the [ingress2gateway Kong provider](https://github.com/kubernetes-sigs/ingress2gateway/tree/main/pkg/i2gw/providers/kong)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](https://docs.konghq.com/kubernetes-ingress-controller/latest/get-started/)getting started guide using the HTTPRoute resource.
To learn more about the Gateway API and Kong, take a look at the following resources:[](https://docs.google.com/document/d/1gIkoZZDg2rpymvbaSIe8MoEx5eGNLLmq-tGACGJCiII/edit)
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
[](https://konghq.com/blog/product-releases/multicloud-cloud-gateways-managed-redis-cache)
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
[](https://konghq.com/blog/product-releases/kong-operator-2-1)
In January 2024, consumers in the United Kingdom made a record-breaking 14.5 million open banking payments. This milestone shows how dramatically the financial services industry has changed. It's the result of years of regulatory work that kicked of
[](https://konghq.com/blog/learning-center/guide-on-open-banking)
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
[](https://konghq.com/blog/engineering/monetize-ai-apis)
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.
[](https://konghq.com/blog/engineering/smarter-event-driven-apis-kong-solace)
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
[](https://konghq.com/blog/engineering/dedicated-cloud-gateways-managed-redis-multi-cloud)
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
[](https://konghq.com/blog/enterprise/ai-input-vs-output-cost-management)