Istio, Linkerd, and Envoy

Knowing what a mesh does is the concept; Istio and Linkerd are the two service meshes a DevOps junior will actually run into on Kubernetes, and Envoy is the proxy underneath the most common one.

TL;DR — in 30 seconds:

• Envoy is a general-purpose, high-performance proxy — not a mesh by itself, but the sidecar proxy that Istio (and several other meshes) is built on.
• Istio is the feature-rich, widely-adopted mesh: Envoy sidecars as the data plane, istiod as the control plane, and a large surface of traffic-management and security CRDs.
• Linkerd is the lighter-weight alternative: its own purpose-built micro-proxy (not Envoy), a smaller feature set, and a deliberate focus on simplicity and low operational overhead.
• Neither is "more correct" — the choice trades Istio's feature breadth and complexity against Linkerd's simplicity and lower resource cost.

1. Where they sit

flowchart LR
    A["Envoy<br/>general-purpose proxy"] --> B["Istio<br/>Envoy sidecars + istiod control plane"]
    C["Linkerd's own micro-proxy"] --> D["Linkerd<br/>lightweight control plane"]

2. Comparing the two meshes

	Istio	Linkerd
Data-plane proxy	Envoy (general-purpose, feature-rich)	Linkerd's own micro-proxy (purpose-built, minimal)
Feature surface	Large — extensive traffic management, security, extensibility	Smaller, deliberately — covers the core mTLS/traffic/observability set well
Operational overhead	Higher — more moving parts, steeper learning curve	Lower — designed to be simple to install and operate
Typical fit	Teams needing fine-grained traffic control or already Envoy-invested	Teams that want the core mesh benefits with minimal operational cost

Both give you mTLS, traffic splitting, retries/timeouts, and per-call observability — the difference is feature depth versus operational simplicity, not whether the core guarantees are present.

Common gotchas

• Assuming Envoy alone is "a service mesh." Fix: Envoy is a proxy — the sidecar/data-plane piece. A mesh also needs a control plane to configure and coordinate the proxies fleet-wide; that's what Istio (or another mesh) adds on top of Envoy.
• Picking Istio by default because it's the most well-known. Fix: if the team just needs mTLS and basic observability with minimal ops burden, Linkerd's smaller footprint may be the better fit — "most popular" isn't "best fit for this team."

Check yourself — a team says 'we're running Envoy as a sidecar, so we have a service mesh.' What's missing from that claim?

Envoy alone is just the data-plane proxy. A service mesh also needs a control plane to configure routing, security, and telemetry across all the proxies centrally — without that (e.g. Istio's istiod), running Envoy sidecars manually isn't yet "a mesh."

Done when: you can name what Envoy is versus what Istio adds on top of it, and state one concrete reason a team might pick Linkerd over Istio.