Service Mesh Field Report #12

Four Questions, and You Can Read Any Envoy Mesh

This is an English translation. The report was first published in German. Read the German original

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.

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?

From the field, for the field

Every report is built on patterns from real mesh setups. If one of them sounds like your cluster, an architecture call is the place to look at it together.

Request an architecture call