kgateway vs Istio Ingress Gateway

Three options at a glance

The decision usually framed as "kgateway vs Istio GW" is really three options once you include where most teams are starting from.

Why move off NGINX Ingress

The case for leaving the Ingress API isn't ideological — it's operational. Same list I've heard from every customer serious about platform engineering.

The Gateway API fixes this structurally: GatewayClass picked by the platform team, Gateway owned by infra (ports, TLS, the network contract), and HTTPRoute / TLSRoute / TCPRoute owned by dev teams, attached explicitly via parentRefs with allowedRoutes filtering by namespace or label. Bad config in one route can't affect another. Non-HTTP protocols are first-class. Propagation is xDS, not reload.

kgateway vs Istio Ingress Gateway

Both are Envoy under the hood. Both implement the Gateway API. The difference is what's around the proxy and what each is optimised for.

Honest framing before the table. Most of the capabilities people associate with kgateway (transformations, ext-proc, JWT validation, rate limiting) are Envoy HTTP filters. Istio Ingress Gateway is Envoy too, so it can do all of them. The real kgateway-vs-Istio-GW difference on those rows is how you configure them: kgateway exposes them as fields on a TrafficPolicy CRD; Istio expresses the same filters via EnvoyFilter (raw Envoy config that Istio's control plane merges in). Same data plane, same filter binaries, different YAML surface. A few items below are more genuinely kgateway-shaped — route delegation, the first-class Backend CRD for non-K8s targets.

kgateway policy surface — OSS vs Enterprise TrafficPolicy

Worth being precise about what's in OSS kgateway and what the enterprise distribution adds — it's a clean superset, not a fork. Same CRD shape, two extra fields.

Worked example — per-tenant + per-endpoint with entRateLimit

Two CRDs: a RateLimitConfig with the descriptor tree, and an EnterpriseKgatewayTrafficPolicy that attaches it to the Gateway and tells the rate-limit filter which request headers to read for each descriptor key. The outer descriptor caps the whole tenant at 1,000 req/min; the inner one caps a specific expensive endpoint within that tenant at 10 req/min.

apiVersion: ratelimit.solo.io/v1alpha1
kind: RateLimitConfig
metadata:
  name: per-tenant-per-path
  namespace: kgateway-system
spec:
  raw:
    descriptors:
    - key: tenant-id                       # outer: per-tenant ceiling
      rateLimit:
        unit: MINUTE
        requestsPerUnit: 1000
      descriptors:
      - key: path                          # inner: per-endpoint within tenant
        value: "/api/v1/expensive"
        rateLimit:
          unit: MINUTE
          requestsPerUnit: 10
    # how request fields map into descriptor keys
    rateLimits:
    - actions:
      - requestHeaders: { descriptorKey: tenant-id, headerName: x-tenant-id }
    - actions:
      - requestHeaders: { descriptorKey: tenant-id, headerName: x-tenant-id }
      - requestHeaders: { descriptorKey: path,      headerName: ":path" }

apiVersion: enterprisekgateway.solo.io/v1alpha1
kind: EnterpriseKgatewayTrafficPolicy
metadata:
  name: per-tenant
  namespace: kgateway-system
spec:
  targetRefs:
  - { group: gateway.networking.k8s.io, kind: Gateway, name: http }
  entRateLimit:
    global:
      rateLimitConfigRefs:
      - { name: per-tenant-per-path }

How the tenant gets identified. x-tenant-id doesn't come from the client — it's written by the gateway from a verified JWT claim via claimsToHeaders on the AuthConfig attached through entExtAuth. So the order on every request is: validate JWT → write x-tenant-id from the tenantId claim → rate-limit filter reads x-tenant-id from the request and keys descriptors off it. See the claims-to-headers KB for the full flow.

An optional second layer — kgateway edge with Ambient east-west

One of the architectural options worth knowing about: kgateway at the cluster edge can be paired with Istio Ambient inside the cluster, when east-west requirements (service-to-service mTLS, fine-grained workload authorization, per-call traces between microservices) eventually come up. This isn't a recommendation — plenty of customers run kgateway alone and don't need the mesh. It's a note that the option exists, what it looks like, and the fact that adopting it later doesn't force a rewrite of the Gateway API resources you already have.

How it works: kgateway terminates external TLS, applies edge L7 policies (JWT validation, rate limits, transformations), and forwards to backends. Enrol the gateway's namespace in ambient (kubectl label ns <ns> istio.io/dataplane-mode=ambient) and that forwarding hop becomes HBONE / mTLS via each destination node's ztunnel. East-west calls between workloads pick up the same mTLS + L4 authz from ztunnel, and any L7 policy that needs to live in the mesh (RequestAuthentication, fine-grained AuthorizationPolicy, tracing) lives on a waypoint. No sidecar injection. Same Gateway API resources keep working.

What you trade for it. You're now running two control planes — kgateway's, and istiod for the mesh — and edge policy vs in-mesh policy use different CRDs. Worth doing when you actually need east-west capabilities, not worth doing pre-emptively.

How to read it. External clients hit kgateway at the edge with HTTPS + a JWT. kgateway terminates TLS, validates the token against the IdP's JWKS, extracts the tenant claim into a header, enforces the rate limit, and forwards to the in-cluster backend. The moment the gateway's namespace is enrolled in ambient (istio.io/dataplane-mode=ambient), that forwarding hop becomes HBONE / mTLS via the destination node's ztunnel, and any L7 policy you want enforced inside the mesh sits on a waypoint. East-west service-to-service calls between backend-api and orders-svc get the same mTLS + authz without any sidecar injection. You can adopt kgateway today and ambient next quarter — same Gateway API resources work in both worlds.

Recommendation

Pricing & sizing

References