Skip to content

What a Service Mesh Is

Kubernetes gets services talking to each other over the network; it doesn't decide how that traffic is secured, retried, or observed. A service mesh is the layer that answers those questions without touching application code.

TL;DR — in 30 seconds:

  • A service mesh adds a sidecar proxy next to every application container — all network traffic in and out of the pod flows through the proxy, not directly between application code.
  • The proxies form the data plane; a separate control plane configures all of them centrally (routing rules, security policy, telemetry collection).
  • Because the proxy — not the application — handles the network, a mesh gives every service the same security, traffic-management, and observability behavior without any app-code changes.
  • Envoy is the proxy most meshes are built on (Istio uses it directly; other meshes use a similar lightweight proxy).

1. The sidecar model

flowchart LR
    subgraph "Pod A"
        AppA["App container"] <-->|"localhost"| ProxyA["Sidecar proxy"]
    end
    subgraph "Pod B"
        AppB["App container"] <-->|"localhost"| ProxyB["Sidecar proxy"]
    end
    ProxyA <-->|"mesh traffic<br/>mTLS, retries, metrics"| ProxyB
    CP["Control plane<br/>(e.g. Istio's istiod)"] -.->|"configures"| ProxyA
    CP -.->|"configures"| ProxyB
  • Sidecar — a second container injected into every application pod. The app talks to localhost; the sidecar intercepts that traffic and handles the actual network hop to the destination pod's sidecar.
  • Data plane — the full set of sidecar proxies across the cluster, doing the actual traffic handling (encrypting, routing, retrying, recording metrics) for every request.
  • Control plane — a central component (e.g. Istio's istiod) that holds the configuration — routing rules, security policy, certificate issuance — and pushes it out to every sidecar. Operators configure the control plane; they never hand-configure individual proxies.
  • Why this beats per-service libraries — before meshes, this behavior (retries, mTLS, metrics) was a library each team had to import and configure consistently in every service, in every language. A sidecar gets the same behavior for free, language-agnostic, with zero app-code changes.

Common gotchas

  • Assuming the mesh replaces Kubernetes networking. Fix: a mesh runs on top of Kubernetes' own pod-to-pod networking — it doesn't replace the CNI, it adds a policy/observability layer above it.
  • Thinking every request goes through the control plane. Fix: the control plane only configures the sidecars; actual request traffic flows sidecar-to-sidecar (the data plane) without touching it.
Check yourself — an application team asks 'do we need to add a library to get retries and mTLS?' now that the cluster has a mesh. What's the answer?

No — that's the point of the sidecar model. The sidecar proxy intercepts the pod's traffic transparently and applies retries, mTLS, and metrics collection at the network layer, with no change to the application's code or dependencies.

Done when: you can draw the sidecar/control-plane/data-plane split from memory and explain why it removes the need for per-service networking libraries.