Four Layers That Process Every Request
Envoy's configuration can be overwhelming because it is deeply nested. Think of it like a series of Russian dolls: each layer opens to reveal another layer of detail. To understand it, break it down into four layers that process a request sequentially.
1. Listeners — "Where am I listening?"
A Listener tells Envoy to open a socket on a specific address and port (e.g., 0.0.0.0:15001). It catches raw bytes off the wire. A single Envoy instance typically has many listeners — one for each port it needs to intercept.
2. Filter Chains — "What do I do with these bytes?"
Once bytes arrive at a Listener, they pass through a pipeline of filters. This is where the real work happens. There are two levels:
- Network Filters (L3/L4): Operate on raw TCP/TLS streams. Examples: tls_inspector (detects TLS), tcp_proxy (forwards raw TCP).
- HTTP Connection Manager (HCM): A special network filter that understands HTTP. It parses the TCP stream into HTTP/1.1 or HTTP/2 frames and then hands off to a sub-pipeline of HTTP Filters (L7) for things like JWT validation, rate limiting, or WASM extensions.
3. Routes — "Where should this go?"
The Route configuration matches the incoming request (by URL path, headers, method, etc.) to a named destination called a Cluster. This is where Istio's VirtualService rules live — weighted routing, retries, and timeouts are all expressed here.
4. Clusters — "Who is the destination?"
A Cluster is a named group of upstream endpoints (IP:port pairs). Envoy uses a load-balancing algorithm (round-robin, least-request, etc.) to pick one endpoint from the Cluster and forward the request.
xDS: The Dynamic Config Protocol
Envoy does not read static config files in production. Instead, it connects to a control plane and receives configuration dynamically over gRPC using the xDS protocol (x Discovery Service). Each resource type has its own API:
| API | Manages |
|---|---|
| LDS (Listener Discovery Service) | Listeners |
| RDS (Route Discovery Service) | Routes |
| CDS (Cluster Discovery Service) | Clusters |
| EDS (Endpoint Discovery Service) | Endpoints |
When you apply an Istio VirtualService, istiod translates it into xDS resources and pushes them to every relevant Envoy sidecar — with no Pod restart required.
Interviewers frequently ask: "How does Istio propagate config changes without restarting Pods?" The answer is xDS. istiod acts as an xDS server. Envoy sidecars maintain a persistent gRPC stream to istiod and receive incremental updates (using the delta xDS variant) whenever a resource changes. This is also why there can be a brief propagation delay between applying a VirtualService and it taking effect — the update must traverse the control plane and be acknowledged by each sidecar.