Service Mesh Vocabulary: Istio, Envoy, and mTLS Explained

Service meshes solve one of the hardest problems in microservices: making service-to-service communication reliable, secure, and observable — without requiring every service team to implement their own retry logic, circuit breaking, and mTLS. If you are working in a Kubernetes environment, service mesh vocabulary appears constantly in architecture reviews, runbooks, and platform team discussions.

Architecture: Planes and Proxies

Service mesh — A dedicated infrastructure layer that handles service-to-service communication. A service mesh provides traffic management, security (mTLS), and observability (distributed tracing, metrics) transparently — without changes to application code. Phrase: “We introduced a service mesh to enforce mTLS between all internal services and get distributed tracing out of the box.”

Data plane — The component of the service mesh that actually handles network traffic: intercepting, routing, load-balancing, and encrypting requests. The data plane is implemented by proxies running alongside each service. Phrase: “Envoy is the data plane — it handles every packet going in and out of the service.”

Control plane — The component that configures and manages the data plane proxies. It distributes policies, certificates, and routing rules to all proxies in the mesh. Phrase: “Istiod is the control plane — it pushes updated routing configuration to Envoy proxies across the cluster.”

Sidecar proxy — A proxy container injected into each Pod alongside the application container. The sidecar intercepts all inbound and outbound traffic, applying mesh policies transparently. Phrase: “The sidecar proxy is injected automatically into every Pod in the production namespace — the application is unaware of it.”

Envoy proxy (pronunciation: “en-voy”) — The open-source high-performance proxy used as the data plane by Istio and many other service meshes. Extremely configurable via xDS APIs. Phrase: “Envoy exposes its stats at /stats/prometheus — we scrape those for the service’s traffic metrics.”

Service Mesh Implementations

Istio (pronunciation: “is-tee-oh”) — The most widely deployed service mesh, using Envoy as the data plane and Istiod as the control plane. Rich feature set: traffic management, mTLS, RBAC, Wasm plugins. Phrase: “We run Istio in ambient mode — no sidecars, which reduces resource overhead significantly.”

Linkerd (pronunciation: “linker-dee”) — A lightweight, Kubernetes-native service mesh written in Rust. Simpler than Istio, with lower resource overhead. Phrase: “We chose Linkerd over Istio — the team found its operational complexity much lower.”

Security: mTLS

mTLS (Mutual TLS) — Both the client and server authenticate each other using X.509 certificates, establishing an encrypted, mutually authenticated connection. In a service mesh, mTLS is enforced transparently by the sidecar proxies. Phrase: “mTLS ensures that only services with a valid certificate issued by the mesh CA can communicate — a rogue pod can’t impersonate a legitimate service.”

Mesh federation — Connecting two or more service meshes (potentially across clusters or clouds) so services in one mesh can communicate securely with services in another. Phrase: “Mesh federation between the EU and US clusters lets the user service in EU call the billing service in US with mTLS and full observability.”

Traffic Management

Traffic policy — Configuration that controls how traffic is routed to a service: load-balancing algorithm, connection pool settings, outlier detection (circuit breaking). Defined in Istio’s DestinationRule.

Retry policy — Configuration specifying how many times a proxy should retry a failed request, under what conditions, and with what backoff. Phrase: “The retry policy retries on 5xx errors up to three times with exponential backoff — no application code change needed.”

Circuit breaking at mesh level — The service mesh proxy automatically stops forwarding requests to an unhealthy upstream endpoint after a threshold of errors, giving it time to recover. Phrase: “The circuit breaker in the DestinationRule ejected the failing instance after five consecutive 503 errors.”

VirtualService — An Istio custom resource that defines routing rules for traffic to a service: traffic splitting, header-based routing, fault injection, timeout. Phrase: “The VirtualService routes 10% of traffic to the canary version and 90% to stable.”

DestinationRule — An Istio custom resource that defines policies applied to traffic after routing: load-balancing policy, connection pool settings, circuit breaker configuration, mTLS settings.

Ingress Gateway — The service mesh entry point for traffic entering the cluster from outside. An Istio IngressGateway manages external-facing traffic, as opposed to service-to-service mesh traffic. Phrase: “TLS termination happens at the Ingress Gateway — east-west traffic inside the mesh uses mTLS end-to-end.”

Observability from the Mesh

Distributed tracing via mesh — The service mesh can automatically propagate trace context (e.g. B3 headers or W3C traceparent) between services and report spans to a tracing backend, providing distributed tracing with minimal application instrumentation. Phrase: “Istio generates trace spans for every hop in the service graph — we didn’t touch application code.”

Observability from mesh — The mesh provides golden signals (latency, traffic, errors, saturation) for every service-to-service interaction as Prometheus metrics, without any application-level instrumentation. Phrase: “The mesh metrics show the auth service P99 latency increased after the last deploy — that’s the bottleneck.”

Practice: Draw a diagram of a two-service architecture with a service mesh and label: data plane, control plane, sidecar proxy, mTLS connection, and Ingress Gateway. Then write a 100-word explanation of the diagram using the vocabulary from this post.