What Kgateway Is and How Fast It Is Growing
Kgateway is an Envoy-based Kubernetes Gateway API implementation from Solo.io. Beyond the standard Gateway API spec, it integrates with service meshes and hyperscalers for hybrid connectivity. The project’s star history shows steady growth. In the last month alone it recorded over 170,000 downloads. David Jumani maintains the project and presented these updates at KubeCon EU 2026.
Helm Overlays: Patching Configs Without Waiting for a Release
Helm exposes common Kgateway configurations, things like images and service type, as first-class parameters. Niche settings, such as DNS config or topology constraints, often are not exposed. Rather than waiting for users to file issues and then cutting a new release, the team introduced overlays. Overlays apply a strategic merge patch on top of existing configuration. Users can customize any Kubernetes resource Kgateway deploys, including the gateway and proxy deployments, without waiting for upstream Helm changes.
Hyperscaler Integrations: GCP and AWS Lambda Backends
Kgateway routes to GCP and AWS Lambda backends directly from an HTTPRoute. A GCP backend reference points to a host and audience. An AWS backend takes an account ID, authentication via Kubernetes secrets, and the Lambda function name. EC2 support is also in progress. This means teams running workloads split between Kubernetes and cloud functions can handle routing in one place, without a separate proxy layer in front of the serverless tier.
Migrating Off Deprecated ingress-nginx
ingress-nginx is deprecated. Kgateway’s team assessed the most common migration paths and identified that 70 to 80% of widely used annotations, including session affinity, rate limiting, and CORS, map to Gateway API equivalents. They are contributing those mappings to the existing ingress2gateway project and maintain a downstream fork for faster iteration. A migration guide with worked examples accompanies the tooling so teams can move without rebuilding routing logic from scratch.
Per-Hostname mTLS CA Validation and Gateway API 1.5.1
Standard Gateway API sets CA certificates per port, not per hostname. On a shared port with multiple hostnames, every hostname gets the same CA. Kgateway added a ListenerPolicy that attaches CA validation to a specific listener section name instead. This matters for multi-tenant deployments that need isolated mTLS boundaries per tenant. The team plans to contribute this upstream. Kgateway now also implements Gateway API 1.5.1, ships a conformance report, and supports listener sets, a feature the team helped promote within the upstream working group.
Notable Quotes
we’ve identified 70 to 80% of the common the common annotations like session affinity rate limiting cost and we are contributing up to to ingress to gateway David Jumani · ▶ 3:44
it allows east west migrate east west traffic as well as as well as it can work as a waypoint David Jumani · ▶ 5:06
within last month we had over 170,000 downloads of our of our product David Jumani · ▶ 0:48
Key Takeaways
- Kgateway reached 170,000 downloads in one month and grows steadily by star history.
- Helm overlays let users patch any Kubernetes resource without waiting for a new release.
- 70-80% of common ingress-nginx annotations now map to Gateway API via contributed tooling.
- Per-hostname mTLS CA validation fills a gap the upstream Gateway API spec does not cover.
- Kgateway implements Gateway API 1.5.1, supports listener sets, and runs as an Istio waypoint.