Envoy Gateway Production Deployment

Deployment Modes

Single Tenant (Default)

• One GatewayClass per Envoy Gateway controller
• Simplest model; suitable for most single-team deployments
• All Gateways share the same controller and Envoy Proxy fleet

Multi-Tenant

• Deploy separate Envoy Gateway controllers per tenant namespace
• Each controller must have a unique controller name in its GatewayClass
• Provides strong tenant isolation at the control plane level
• Install via separate Helm releases with distinct --set config.envoyGateway.gateway.controllerName=...

Gateway Namespace Mode

• Envoy Proxy pods deploy in the Gateway's namespace instead of the controller namespace
• Provides stronger workload isolation: proxy runs alongside the application
• Enables JWT authentication between proxy and controller for hardened communication
• Enable with envoyGateway.provider.kubernetes.deploy.type: Namespace

Merged Gateways

• Merge listeners from multiple Gateway resources into a single Envoy Proxy fleet
• All merged Gateways share a single IP address / load balancer
• Useful for consolidating ingress when teams own different Gateways but share infrastructure
• Enable with mergeGateways: true on the GatewayClass parametersRef (EnvoyProxy)

Performance Tuning

• Connection timeouts: set explicitly in ClientTrafficPolicy and BackendTrafficPolicy. Never rely on Envoy defaults.
  • timeout.http.requestTimeout — total time for the client to send a complete request
  • timeout.http.idleTimeout — close connections idle longer than this
• HTTP/2 max concurrent streams: limit to 100 to prevent a single connection from monopolizing resources
• Buffer limits: set to 32 KiB for both listener and cluster buffers to cap memory under load
  • Configure via EnvoyProxy spec.bootstrap or EnvoyPatchPolicy
• Resource requests/limits: always set CPU and memory on Envoy Proxy pods via EnvoyProxy spec.provider.kubernetes.envoyDeployment.container.resources
• Horizontal scaling: use HPA on the Envoy Proxy Deployment; scale on CPU utilization (target 60-70%)
• Keep-alive: enable TCP keep-alive on backend connections to avoid connection resets through cloud load balancers

Observability

Access Logging

• Configure via EnvoyProxy spec.telemetry.accessLog
• Sinks: File (stdout/path) or OpenTelemetry (gRPC collector)
• Use structured JSON format for machine parsing
• Include at minimum: method, path, response code, duration, upstream host

Metrics

• Expose Prometheus metrics via EnvoyProxy spec.telemetry.metrics
• Scrape from Envoy Proxy pods on the admin port (default 19001)
• Key metrics: envoy_http_downstream_rq_total, envoy_http_downstream_rq_xx, envoy_cluster_upstream_rq_time
• Enable Envoy Gateway controller metrics for control plane health

Tracing

• Configure distributed tracing via EnvoyProxy spec.telemetry.tracing
• Export to OpenTelemetry collector (gRPC or HTTP)
• Set appropriate sampling rate: 1-10% in production, 100% in staging
• Propagate trace context headers (traceparent, tracestate)

Operations

Installation

helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.7.0 \
  -n envoy-gateway-system \
  --create-namespace

• Always pin Helm chart versions — never use latest or omit --version
• Use helm upgrade --install for idempotent deployments

GitOps

• Manage all Gateway API resources via GitOps (ArgoCD, Flux)
• Store Gateway, Route, and Policy manifests in version control
• Implement mandatory PR reviews for all gateway configuration changes
• Use SCM branch protection rules on the main branch

Upgrade Strategy

• Upgrade Envoy Gateway controller first, then verify CRD compatibility
• Test upgrades in a staging environment that mirrors production topology
• Review release notes for breaking changes in CRD schemas or default behavior
• Back up CRD instances before upgrading (kubectl get -o yaml)