Gateway API resources become managed Envoy proxies
Envoy Gateway watches Kubernetes Gateway API objects and translates them into infrastructure plus xDS configuration for Envoy Proxy. A GatewayClass selects the controller, a Gateway declares listeners, and routes attach application traffic. Project policies cover client and backend traffic, security, telemetry, and the generated Envoy deployment. Platform teams get a declarative interface while application namespaces work with standard route resources instead of controller-specific annotations.
The project can also manage Envoy as a standalone application gateway, but Kubernetes is the main operational story. Envoy Gateway owns the control plane; Envoy remains the data plane carrying requests. That split gives users Envoy's protocol and filter capabilities without asking every operator to author raw bootstrap configuration. It also creates two systems to observe: the controller may accept a resource while the proxy later rejects generated xDS.
Version 1.9.0 is active, with compatibility work still moving
GitHub listed 2,990 stars, 767 combined issues and pull requests, and a last push on August 26, 2026. Release v1.9.0 arrived August 15. Its changes cover Gateway API compatibility, listener conflicts, backend TLS, health checks, status, Helm permissions, security contexts, metrics, and dependency upgrades. That is active project health, while the large combined queue reflects feature work and maintenance rather than 767 confirmed bugs.
What happened when we ran it
Our sandbox downloaded 550 Go packages in 78 seconds, then built the repository in 215 seconds. The test step ran for 144 seconds and exited with code 1. The harness summarized 53 passing and 5 failing results out of 58. commit d32f282 therefore compiled successfully but did not pass its complete Go test command in our unprivileged Debian container with 3 CPUs and 8 GB of RAM.
The provided log tail lists many generated client, informer, lister, and protocol packages with [no test files], then ends at FAIL. It does not identify the five failed results or print an error message for them. We will not assign a cause that the tail does not show. A contributor should retain the full test log and run the failed packages individually before changing dependencies or system configuration.
The repository measured 80.1 MB across 6,936 files and roughly 306,564 source lines. It had 13 CI workflow files and a tests directory, with no file named Dockerfile at the root. Our build check did not create a Kubernetes cluster or send traffic through an Envoy data plane, so it says nothing about upgrade safety or request handling.
Full translation can delay endpoint changes in large clusters
Issue 9777 describes EndpointSlice updates traveling through a full resource-tree reconcile, Gateway API translation, xDS translation, and snapshot publication. In clusters with tens of thousands of routes and expensive policy patches, the report says a translation can take seconds to tens of seconds. Pod churn can then keep Envoy behind current endpoints because each cheap, frequent endpoint update waits for the most expensive configuration path.
That issue proposes an EDS-only fast path. Teams operating ordinary route counts may never notice the problem, but high-churn clusters should test it directly. During a rollout, record the time from EndpointSlice change to the Envoy endpoint view, then repeat while applying route and policy changes. A control plane that eventually converges can still send traffic to terminated pods during the gap.
Proxy rejection does not always reach Kubernetes status
Issue 9198 reports that a malformed telemetry format can be rejected by Envoy while the Kubernetes resource lacks a useful failure condition. The old proxy may keep its last good configuration, while a newly created proxy has no cached copy and can fail on the bad listener. A rollout or node replacement can therefore turn a latent configuration error into an outage.
Status cannot be the only deployment check until NACK propagation covers these cases. Watch controller logs, xDS NACK metrics, proxy readiness, and a synthetic request through every important listener. Version 1.9.0 added more status and metrics work, but the August issue remains open. An accepted resource proves the controller understood it, not that every Envoy instance applied it.
Edge modes need scenario-specific testing
Issue 8816 says session persistence behaves differently when backend mutual TLS points through a Service FQDN. Direct Service routing can bind the cookie to a pod endpoint, while the FQDN path can bind it to the Service address and allow later requests to land on different pods. Applications depending on sticky sessions should test the exact Backend and TLS combination.
Issue 9853 reports that shutdown-manager failed to reach Envoy's local admin port in a host-network deployment using Envoy Gateway v1.7.1. Its log shows connection refusals during the drain sequence. Version scope matters, but host networking is still a configuration to verify before relying on graceful termination. Uncommon combinations take different paths through translation and lifecycle code.
Choose it when Gateway API is a platform contract
Envoy Gateway earns its place when Gateway API is the contract between application owners and networking operators. Standard resources, versioned documentation, active releases, and Envoy's data plane make a credible foundation. The 215-second build and 550 downloaded packages show the contributor cost, while our 5 failed results require follow-up before modifying the code.
Begin with supported core routes and a small policy set. Add backend TLS, HTTP/3, host networking, custom extensions, or very large route counts one at a time with status and data-plane checks. If the organization only needs a few ingress routes, Traefik or NGINX Gateway Fabric may demand less attention. Envoy Gateway pays off when a shared Kubernetes platform needs the extra control.