The ingress gateway for a Kubernetes cluster is one of the most important networking components. Without ingress, no outside clients can reach the APIs and services hosted within the Kubernetes cluster. When evaluating the best alternative to Ingress NGINX, we believe it is critical to choose a replacement that is hardened, matured, and running at scale in enterprises worldwide in tier-0 architectures. To achieve this, not only do you need a robust data plane, such as Envoy proxy, but you need a battle tested control plane and one that implements the Kubernetes Gateway API. Together the data plane and control planes must deliver top-tier performance, offer rich features, and be backed by a vendor-neutral foundation with a vibrant community.
In this blog, we’ll explain why we believe kgateway is the right implementation of data plane and control plane and is the best alternative to Ingress NGINX.
History of kgateway:
Kgateway originated as an open-source project named Gloo. Gloo was created by engineers at Solo.io in 2018, and over time it became the most mature and widely deployed Envoy-based API gateway in the market. Built on open source and open standards, Gloo is Kubernetes-native and implements the Kubernetes Gateway API.
At KubeCon NA 2024, Solo.io announced its intention to donate the Gloo open source project to the Cloud Native Computing Foundation (CNCF), to enrich the broader cloud native ecosystem. Since kgateway was accepted by the CNCF as a sandbox project, we have witnessed strong growth on the project across all metrics such as GitHub stars, project downloads, and contributions.
For example, you can see the GitHub star inflection point around March 2025, which is when the CNCF TOC accepted kgateway as an official CNCF project. This momentum coincided with significant AI innovation in the project, including support for inference, LLM, MCP, and agent gateway use cases. 🚀
Envoy Proxy:
Envoy Proxy is a powerful, extensible, proxy built on C++ and is a graduated project in the CNCF. This means Envoy is not owned by any one vendor, which is a big reason why we’ve seen an explosion in projects using it to power Layer 7 capabilities, including API gateways, service meshes, and even CNIs. Envoy is supported and battle tested in production by hundreds of companies.
The primary goal of the Envoy project is the open source edge and service proxy, not as the control plane for Envoy. When reviewing a project, it is important to keep its primary goal in mind as that is what was evaluated when the project was accepted as a CNCF graduated project.
Many projects have built control planes for Envoy, including kgateway, Istio, Cilium or Kuma, and others. While these projects all provide Envoy control planes, kgateway is the only project whose primary mission is to deliver the best API gateway that implements the Kubernetes Gateway API, with Envoy as its data plane. The primary goal of kgateway is not service mesh or CNI, it is to be the best API gateway for Kubernetes.
If you believe Envoy is the best data plane proxy for your needs, the next step is to choose the ideal control plane that is not only scalable, but also matches your feature requirements.
Design kgateway for Scalability
When we started building Gloo (now kgateway) seven years ago, we used a snapshot-based model that recalculated everything on every update—whether it was a new route, an update, or a backend change. This meant even small changes triggered a full control plane recalculation. With Kubernetes, where pods and backends change constantly, this was not scalable.
Managing resource dependencies via manual references like targetRefs and extensionRefs also proved cumbersome. Dependency resolution sometimes failed, creating reliability issues.
Learning from that experience, we designed kgateway using the battle-tested krt framework to handle dependency tracking automatically. With this approach, only affected objects are retranslated when a change occurs, ensuring fast updates and efficient scaling.
To dive deeper into our control plane design, check out our previous blog post.
Check out the numbers
Our CNCF Top Committer Award winner, John Howard, developed and ran one of the most thorough Gateway API benchmarks in the industry. The benchmark compared different implementations across key metrics, including route propagation time, error rates, the ability to handle route changes safely without downtime, traffic throughput and latency, and CPU utilization.
Adding a new route to the gateway is one of the most common scenarios. For example, the following test shows route propagation times when routes are added sequentially, up to 3,000 routes:
From the route propagation test, kgateway uses less time to propagate routes than any other implementations. During the tests, we also observed that kgateway was not only the fastest at propagating routes, but also achieved zero errors:
To learn more about this in-depth Gateway API benchmark, check out John’s gateway-api-bench repository.
Listening to the Community
We value feedback from our community and actively engage our community through our bi-weekly community meetings and the kgateway slack channel.
One piece of feedback we heard repeatedly was that some core features were only available in the enterprise version and not in open source kgateway. Balancing the needs of open source with building a sustainable project we can continue to fund was a difficult decision.
After several rounds of thoughtful discussion, we decided to open source many of our core enterprise features. We have been tracking these feature gaps in the kgateway GitHub repository, and most of them have already been implemented. These features include, but are not limited to:
- API key based authentication
- OAuth2/OIDC Authentication support
- External auth (extAuth) support via HTTP
- Gzip compression
- JWT validation
- Basic authentication
- Regex-based path rewriting
What Users Say
Are you evaluating the best alternative for Ingress NGINX? Here’s what our users say about kgateway:
“We have been using kgateway for a long time. Thank you for the excellent work on kgateway! I appreciate the project’s focus on providing a lightweight, scalable solution for managing API gateways in cloud-native environments.”
Suresh Punuru, Platform Engineer, 24x7 Systems Inc.
“We decided to use kgateway as part of our migration from Ingress to Gateway API to improve consistency, authentication, and traffic handling across our Kubernetes platform. The built-in external auth support, OpenTelemetry integration, and high-performance routing have been a great fit for our use case. We’re also testing the Waypoint proxy integration with Istio Ambient Mesh in a proof-of-concept phase, and so far it has helped us validate our future service mesh architecture.”
Javier Orellana, Senior DevOps Engineer, Xepelin
“Kgateway brings great enrichment to MCP topics within Kubernetes. Along with Gateway API, it enables more advanced options to become possible. The ability to choose which proxy modes you want to use makes it a perfect choice.”
Igor Vojinović, DevOps Engineer, Resident
Wrap Up
With a rich history of building Envoy-based API gateways, a track record as one of the most performant API gateways on the market, CNCF stewardship, a community that actively listens, rapidly closing feature gaps, and continuous innovation, we believe kgateway is the best alternative to Ingress NGINX.
In a future blog post, we’ll cover how you can use the Ingress2gateway migration tool to help move from Ingress NGINX to kgateway.
%20a%20Bad%20Idea.png)
%20For%20More%20Dependable%20Humans.png)
