Envoy guide

What Envoy does in production

Envoy sits in the data path between clients and backends. It terminates connections, applies routing rules, load-balances across hosts, enforces timeouts and retries, handles TLS, and emits detailed metrics and access logs. Unlike a static nginx config, Envoy is built for dynamic discovery — control planes (Istio, Consul, custom controllers) push updates via xDS without restarts.

Where you meet Envoy

• Kubernetes / service mesh — sidecar proxy next to each pod (Istio, Linkerd uses different proxy)
• API gateway — edge ingress with advanced routing and auth filters
• Internal LB — gRPC/HTTP load balancing with health checks and outlier detection
• Bridging protocols — HTTP ↔ gRPC, TLS origination, TCP proxy

How a request is handled

1. Listener — client connects to a bound address/port (e.g. 0.0.0.0:10000)
2. Filter chain — network/HTTP filters parse the request (TLS, HTTP connection manager)
3. Route match — virtual host and route table match host, path, headers
4. Cluster — route selects a cluster (group of upstream hosts)
5. Load balance — pick an endpoint; apply timeouts, retries, circuit breaking
6. Response — return to client; log to access log; increment stats

Core configuration objects

• Listener — ingress socket + filter chain
• Route configuration — virtual hosts, paths, redirects, direct responses
• Cluster — upstream service; LB policy, health checks, connection pool
• Endpoint — IP:port of a backend instance (often from EDS)
• Secret — TLS certs and keys (SDS)

Static vs dynamic (xDS)

Static — full config in envoy.yaml for simple deployments and learning. Dynamic (xDS) — control plane streams updates:

• LDS — listeners
• RDS — routes
• CDS — clusters
• EDS — endpoints
• SDS — secrets (TLS)
• ADS — aggregated delivery of all xDS over one stream

In Istio, istiod is the control plane; Envoy sidecars receive config automatically. See the Kubernetes lab for workload debugging alongside mesh issues.

Admin interface and observability

Envoy's admin API (default 127.0.0.1:9901, Istio often 15000) is essential for troubleshooting:

• /config_dump — effective configuration (listeners, routes, clusters)
• /clusters — upstream health, cx counts, circuit-breaker state
• /stats — counters and histograms (Prometheus format at /stats/prometheus)
• /listeners — active listeners and ports
• /server_info — version, uptime, state

Access logs (JSON or text) show per-request upstream host, response flags, and latency — configure in the HTTP connection manager filter.

Load balancing and resilience

• Policies — round robin, least request, ring hash, random
• Health checks — active HTTP/TCP checks; unhealthy hosts removed
• Outlier detection — eject flaky hosts (passive health)
• Retries & timeouts — per-route; beware retry storms
• Circuit breakers — limit connections/requests per cluster

Envoy vs nginx / HAProxy / Traefik

nginx and HAProxy are mature, operator-friendly proxies with file-based config — see Nginx and HAProxy labs. Traefik targets dynamic Docker/K8s ingress with less boilerplate. Envoy prioritizes API-driven config, deep observability, gRPC first-class support, and pluggable WASM/Lua filters — at the cost of steeper config complexity. Choose Envoy when a control plane or mesh already manages it; choose nginx/Traefik for simpler edge ingress.

Key files and deployment

• Config — /etc/envoy/envoy.yaml or bootstrap from Istio
• Binary — envoy (often in container envoyproxy/envoy)
• Validate — envoy --mode validate -c envoy.yaml
• Logs — stdout or /var/log/envoy/

Learning resources

• Envoy documentation — envoyproxy.io/docs
• Configuration overview — envoyproxy.io — configuration
• Admin interface — envoyproxy.io — admin
• xDS protocol — envoyproxy.io — xDS