Four Questions, and You Can Read Any Envoy Mesh
Almost every mesh runs the same engine. Today I take it apart. Don’t fear the depth, there are exactly four parts.
- Date
- Topic
- Envoy
- Sources
- 3
- Reading time
- 2 min
- Version
- Translation
Last week, this is what it said here: almost every mesh runs the same engine. Today I take it apart. Don’t fear the depth, there are exactly four parts.
Figure as text
Diagram in three layers: at the top, the Istio CRDs Gateway, VirtualService, DestinationRule, and ServiceEntry as a translation layer; in the middle, the Envoy pipeline as four questions, Listener, Route, Cluster, and Endpoint, tracing a request to a pod IP; at the bottom, the diagnostics layer with istioctl proxy-config subcommands and the flags NR, UO, and UF. The closing line reads: product YAML can be relearned, the four questions stay.
Every request passing through Envoy answers four questions, in order.
Listener: Where does traffic arrive? Port, protocol, filter chain. This is where it’s decided whether anyone is listening at all.
Route: Which rule matches? Host, path, and headers get matched, and the request is assigned its destination.
Cluster: How is that destination configured? Load balancing, TLS, timeouts, circuit breakers. The destination as a group, with operating rules.
Endpoint: Which concrete addresses are healthy right now? Only here does configuration become a real packet to a real IP.
That’s the whole engine. Everything else is translation. An Istio Gateway writes listeners. A VirtualService writes routes. A DestinationRule writes clusters, subsets and circuit breakers included. A ServiceEntry creates clusters and endpoints for external destinations.
If you read report #8, you can see it now: istioctl proxy-config asks for listeners, routes, clusters, and endpoints because the diagnostic path walks exactly these four questions. Plus a fifth compartment for certificates, secrets. The Envoy flags fall into place too: NR means question two has no answer. UO fails at question three, where the circuit breaker lives. UF at question four, the address doesn’t respond.
And because Kuma, Consul, and the Istio distributions run the same engine, their debug output can be read with the same four questions. A config_dump from the Envoy admin interface looks the same everywhere.
For the organization, that means: don’t train your team on a product, train it on the engine. Product YAML can be relearned in weeks. The four questions will carry you through every platform decision.
Next week gets concrete: moving off AWS App Mesh before the lights go out at the end of September. A scaffold you can take with you, plus an honest answer to when Istio is the right destination and when it isn’t.
Which of the four questions refused to answer during your last debugging session?
