mrvitej.in

DevOps · CNCF daily

Kgateway: A Kubernetes-Native API Gateway Built on Envoy and the Gateway API

CNCF Sandbox. A control plane that turns Kubernetes Gateway API resources into Envoy configuration for ingress, routing and API traffic management, donated by Solo.io from the Gloo Gateway project.

6 min read

CNCF Sandbox

  • Kgateway
  • Envoy
  • Gateway API
  • Kubernetes
  • Istio
CNCF project page

Kgateway is a Kubernetes-native API gateway. Its control plane watches Kubernetes Gateway API resources and turns them into configuration for Envoy proxies that carry traffic into, out of and between workloads. It addresses the need for a standards-based replacement for annotation-driven ingress controllers, with routing, authentication, rate limiting and resilience policies expressed as Kubernetes resources. Solo.io announced at KubeCon North America 2024 that it would donate its Gloo Gateway open source project to the CNCF, and the project was renamed kgateway. It was accepted into the CNCF at the Sandbox level on March 4, 2025.

CNCF daily · Sprint 2, day 3 · API Gateway

At a glance
Category API Gateway
CNCF status Sandbox. Accepted March 4, 2025
Written in Go (control plane); data plane is Envoy
License Apache 2.0
Current release line kgateway 2.4 (2.4.4 listed as the latest release in the project’s GitHub releases)
Gateway API support Standard channel v1.2.1 to v1.6.1 for the 2.4 line, with conformance to the Gateway API and the Inference Extension reported from 2.1
AI features Since 2.3.0 the AI and agent control plane lives in the separate agentgateway project; kgateway focuses on Envoy

Architecture

flowchart TB
  GAPI[Gateway API resources<br/>GatewayClass, Gateway, HTTPRoute] --> CP[kgateway control plane<br/>translates and validates]
  POL[Policy resources<br/>TrafficPolicy and others] --> CP
  CP -->|xDS configuration| ENV[Envoy proxies<br/>one deployment per Gateway]
  CP -->|deploys and manages| ENV
  CLIENT[Clients] -->|HTTP, HTTPS, gRPC| ENV
  ENV --> SVC[Backend Services<br/>pods in the cluster]
  ENV --> EXT[External backends<br/>cloud services, other clusters]
  ENV -->|metrics and traces| OBS[Prometheus, Grafana,<br/>OpenTelemetry]
  ISTIO[Istio ambient mesh] -->|waypoint integration| ENV
Component Responsibility
Control plane Watches Gateway API and policy resources, validates them, translates them into Envoy configuration and pushes it over xDS.
Envoy data plane Proxies are deployed per Gateway and enforce routing, TLS, retries, timeouts, authentication and rate limits.
Gateway API resources GatewayClass, Gateway and HTTPRoute (plus related route kinds) describe listeners and routing in a vendor-neutral way.
Policy resources Kgateway extensions, such as traffic and authentication policies, attach to Gateways or routes for behaviour beyond the base API.
Waypoint integration The project can act as a Layer 7 waypoint proxy for Istio ambient mesh.

Design principle. Kgateway keeps configuration on the Kubernetes Gateway API, the community standard that succeeds Ingress, and adds extensions only where the standard stops. That keeps routes portable across implementations while the project supplies the Envoy-based data plane and the operational features around it.

Production reference design

A typical deployment on EKS, GKE, AKS or on-premises Kubernetes installs the Gateway API CRDs and kgateway through Helm, then manages Gateways and routes through GitOps.

  1. Install the Gateway API CRDs, using a release within the supported range: 
    kubectl apply --server-side -f \
  https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml
  2. Install kgateway with its CRDs chart and then the control plane chart, pinning the version: 
    helm upgrade -i kgateway-crds oci://cr.kgateway.dev/kgateway-dev/charts/kgateway-crds \
  --namespace kgateway-system --create-namespace --version v2.4.4
helm upgrade -i kgateway oci://cr.kgateway.dev/kgateway-dev/charts/kgateway \
  --namespace kgateway-system --version v2.4.4
  3. Declare a Gateway with TLS, restricting which namespaces may attach routes: 
    apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: public
  namespace: gateways
spec:
  gatewayClassName: kgateway
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: shop.example.com
      tls:
        mode: Terminate
        certificateRefs:
          - name: shop-example-com
      allowedRoutes:
        namespaces:
          from: Selector
          selector:
            matchLabels:
              gateway-access: "true"
  4. Attach application routes from the owning namespace, with a timeout and weighted backends for a canary: 
    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: orders
  namespace: shop
spec:
  parentRefs:
    - name: public
      namespace: gateways
  hostnames: [shop.example.com]
  rules:
    - matches:
        - path: { type: PathPrefix, value: /api/orders }
      timeouts:
        request: 10s
      backendRefs:
        - name: orders-v1
          port: 8080
          weight: 90
        - name: orders-v2
          port: 8080
          weight: 10
  5. Run the data plane for availability: scale the Envoy deployments, spread them across zones, and use a cloud load balancer Service in front.
  6. Add policies and observability for authentication, rate limiting and retries as the policy resources support them, and scrape Envoy metrics into Prometheus and Grafana.

Typical production uses are replacing ingress-nginx, shared edge gateways for many teams with namespace-level delegation, API traffic management, and an Envoy waypoint for Istio ambient mesh.

Operational considerations

  • Scaling: scale the Envoy proxy deployments with CPU or request rate (the project supports bring-your-own HPA), and keep route counts reasonable per Gateway; separate Gateways per team or domain limit blast radius.
  • High availability: run multiple proxy replicas across zones with PodDisruptionBudgets, and keep the control plane replicated; existing Envoy proxies keep serving traffic with their last configuration if the control plane is briefly unavailable.
  • Security: terminate TLS with certificates from cert-manager, restrict allowedRoutes and use ReferenceGrant for cross-namespace references, and keep policy attachment limited to platform teams.
  • Cost and sizing: each Gateway creates its own proxy deployment and usually a cloud load balancer, which adds cost; share Gateways across teams where isolation permits.
  • Common pitfalls: mixing Gateway API CRD versions outside the supported range, moving Ingress annotations across one by one instead of translating them to routes and policies, and relying on the Envoy-based AI features that were deprecated in favour of agentgateway. Read the release notes before each minor upgrade, since the project is at Sandbox maturity and moves quickly.

Adoption

Kgateway has no formal adopters list on its CNCF page or repository. In Solo.io’s own writing, engineers at 24x7 Systems, Xepelin and Resident describe using it: Xepelin adopted it while moving from Ingress to the Gateway API and is testing the Istio ambient waypoint integration. The project descends from Gloo Gateway, which Solo.io describes as widely deployed, and Solo.io sells an enterprise distribution built on it.

Alternatives

Solution Model Best suited to
Envoy Gateway (Envoy project, CNCF Graduated) Gateway API implementation on Envoy Teams wanting the Envoy project’s own Gateway API controller
Istio ingress gateway (CNCF Graduated) Gateway API on Envoy within a mesh Clusters already running Istio
Cilium Gateway API (CNCF Graduated) eBPF-based networking with Gateway API Clusters already using Cilium
NGINX Gateway Fabric (NON CNCF) Gateway API on NGINX Organisations standardised on NGINX
Traefik, Kong, Contour Gateways and ingress controllers with Gateway API support Teams that prefer those products’ features and ecosystems

Strengths and limitations

Strengths Limitations
Standards-based on the Kubernetes Gateway API Sandbox maturity; governance and APIs are still evolving
Envoy data plane with a mature feature set Extension policies are kgateway-specific and not portable
Reported Gateway API and Inference Extension conformance Fewer public adopters than long-established gateways
Can serve as an Istio ambient waypoint AI functions moved to a separate project, which readers must track
Backed by a vendor and an open governance model Per-Gateway proxy deployments add resource and load balancer cost

Recommendation

Assess, moving to Trial for teams replacing ingress-nginx that already plan to adopt the Gateway API. Start with a non-production Gateway, translate a few routes with the standard resources, and measure behaviour against your current controller before moving traffic. Production-critical edges that need the widest adopter base should compare Envoy Gateway, Istio or Cilium alongside it, given the Sandbox status.

References: CNCF project page · kgateway on GitHub · CNCF: Advancing open source gateways with kgateway · CNCF: Kgateway v2.1 is released · Solo.io: Kgateway as an alternative to ingress-nginx · kgateway documentation

Spotted something wrong or out of date?Suggest a correction. I review every suggestion before changing the page.