kgateway turns Kubernetes Gateway API declarations into the configuration used by Envoy proxies to serve application traffic. Teams use it to manage shared gateways and application routes through Kubernetes resources, with additional policies where the selected implementation supports them. The controller and the proxy have different roles: one watches desired configuration, while the other handles requests. Its features and operating model should be evaluated for the exact release being deployed.
Deployment and operating notes
Consider it for application traffic routing when its supported route features and policy extensions fit the platform's requirements. Its Gloo ancestry does not make an older Gloo configuration or enterprise feature set interchangeable.
Chart ownership
The kgateway project documents OCI charts for kgateway and kgateway-crds under oci://cr.kgateway.dev/kgateway-dev/charts. Its installation sequence also requires a compatible Gateway API CRD installation. Keep those schema and controller lifecycles explicit in GitOps.
Before adoption
Inventory rewrites, authentication, rate limits, TLS and cross-namespace references before translating routes. Compare required behavior on a separate gateway address and verify denied requests as carefully as successful requests. Check the release's conformance and extension support; use of Gateway API alone does not prove portability. Keep the old data plane available until cutover and rollback behavior have been demonstrated.
Follow the official Helm instructions. The historical Gloo entry provides context for older installations.
Sources & further reading
Spotted something that needs another look?
Help improve this page →