Service Mesh Architecture

The ICA and CCA blueprints both test a mesh's surface — the CRDs you write, the CLI verbs you run, the policy you configure. Neither exam asks you to explain why the thing underneath looks the way it does, or why three CNCF projects that all claim to solve "service mesh" ship such different-looking answers. This page is that missing layer. It compares three real architectures — Istio's classic Envoy sidecar and Linkerd's deliberately minimal micro-proxy on one side, and two genuinely different sidecarless designs, Istio's own Ambient Mode and Cilium's native eBPF mesh, on the other — against the one structural idea every mesh shares underneath: a control plane that decides, and a data plane that acts. It closes with the question none of the exams ask at all: whether a mesh is worth the operational cost you are about to take on.

Every mesh is two systems wearing one name

☺ Like you're 10: One part of the mesh decides the rules. A completely different part actually touches every message. They're not the same program, even when people talk about "the mesh" as if it were one thing.

"Service mesh" describes a shape, not a single piece of software, and every real implementation — Istio, Linkerd, Cilium's own mesh — splits into the same two systems. The control plane (istiod for Istio, cilium-operator plus the per-node cilium-agent for Cilium, linkerd-destination and linkerd-identity for Linkerd) watches the Kubernetes API, computes what every workload's routing rules, TLS identity and authorization policy should be, and continuously pushes that computed state down. The data plane is whatever actually sits on the path of a real packet or request and enforces what it was told — an Envoy sidecar, a per-node ztunnel, an eBPF program attached to a kernel hook, a linkerd2-proxy. The control plane never touches a single byte of application traffic; the data plane never decides policy on its own. That separation is what makes "the control plane is down" and "the mesh is down" two completely different sentences.

The sidecar model: one proxy per pod

☺ Like you're 10: One guard per apartment door. Simple to reason about, and every new apartment needs its own guard, no exceptions.

Istio's original architecture, and the only architecture Linkerd has ever shipped, injects a proxy container into every pod that joins the mesh. A Kubernetes mutating admission webhook intercepts pod creation and adds the sidecar automatically — which means injection only happens at creation time. Label a namespace for injection and nothing happens to the pods already running in it; they need a rollout restart before they're actually in the mesh, the single most common "why isn't this pod showing a sidecar" support ticket on any mesh team. Once injected, every request the app container sends leaves through its own local proxy first, and every request it receives arrives through that same proxy — which is what lets the proxy enforce mTLS, retries, timeouts and authorization without the application ever calling a library or knowing the mesh exists.

# A pod with an injected sidecar shows two containers, not one
$ kubectl get pods -n prod
NAME                        READY   STATUS    RESTARTS   AGE
checkout-7d9f6c8b4d-x2k9p   2/2     Running   0          3h

# Istio's proxy defaults are real resource consumers — one per pod, not per node
$ kubectl get pod checkout-7d9f6c8b4d-x2k9p -n prod -o jsonpath='{.spec.containers[1].resources}'
{"limits":{"cpu":"2","memory":"1Gi"},"requests":{"cpu":"100m","memory":"128Mi"}}

# Existing pods are never retrofitted — injection only fires at pod creation
$ kubectl label namespace prod istio-injection=enabled
$ kubectl rollout restart deployment -n prod   # required, every time

Istio and Linkerd made opposite bets on what that sidecar should be. Istio's sidecar is Envoy — a general-purpose, extremely feature-rich proxy originally built at Lyft, driven by the xDS configuration protocol, capable of nearly anything you can express in a VirtualService or DestinationRule. That breadth is also its resource footprint: Envoy is a substantial binary with a correspondingly real CPU and memory budget per pod, doubled across every pod on the cluster. Linkerd's linkerd2-proxy is the opposite bet on purpose — written in Rust specifically to be small, and deliberately narrow in what it does: mutual TLS, retries and timeouts, golden-signal metrics, and basic traffic splitting, with none of Istio's expansive header-manipulation and fault-injection surface. Linkerd's own positioning is explicit about this trade: fewer features, in exchange for a proxy light enough that most teams stop thinking about its overhead at all. Neither choice is wrong — they're optimizing for different things, and "which sidecar" is really "how much mesh do you actually need."

Sidecarless, take one: Istio's own Ambient Mode

☺ Like you're 10: Instead of a guard per door, one small team covers a whole hallway — and a second, fancier team only shows up on the floors that actually asked for extra scrutiny.

Istio didn't wait for a competitor to solve the sidecar's overhead problem — it shipped its own sidecarless mode, Ambient, splitting the data plane into two layers instead of one. ztunnel runs once per node, handles every pod on that node, and does exactly the part of the job that scales cleanly without per-pod state: mTLS, workload identity, and basic L4 authorization. No injection webhook, no sidecar container, no rollout restart to join — a namespace enrols with a label (istio.io/dataplane-mode: ambient) and every existing pod is covered immediately. Layer two is the waypoint proxy, a full Envoy instance deployed only for the namespaces or service accounts that actually need Layer-7 features — header-based routing, path-based authorization, fault injection. Most workloads never get one; they run on ztunnel alone and never pay Envoy's cost at all. It's the same idea as an office giving every floor basic security, and only wiring a fancier badge reader onto the doors that actually need it.

Sidecarless, take two: Cilium's native mesh

☺ Like you're 10: This building was never guarded by people at doors in the first place — the hallways themselves were built to watch everyone walking through them. Adding "mesh" features barely costs anything extra, because most of the watching was already happening.

Cilium's sidecarless story is a different kind of different. Ambient still adds a dedicated per-node proxy process to do its L4 job. Cilium doesn't need to, because it's already your CNI — every packet on the cluster is already passing through eBPF programs attached to kernel hooks before a single mesh feature gets switched on. Identity-based authorization, mutual encryption via WireGuard or IPsec, and load balancing are consequences of capabilities Cilium's datapath already has for ordinary networking duty, not new machinery bolted on for "mesh." Only Layer-7 rules — an HTTP method, a path, a header match — need something to actually parse the protocol, which eBPF alone can't do; for those, Cilium spins up one Envoy instance per node, invoked only for the specific flows a policy's rules.http block asks it to inspect. The rest of Cilium's mesh behaviour never leaves the kernel at all. eBPF & the Cilium Datapath is the page that goes underneath this one and explains exactly how that kernel-level enforcement actually works.

# Enabling Cilium's L7 visibility/enforcement doesn't add a sidecar —
# it tells the existing per-node Envoy to start parsing THIS traffic.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: checkout-l7
  namespace: prod
spec:
  endpointSelector:
    matchLabels: { app: checkout }
  ingress:
    - fromEndpoints:
        - matchLabels: { app: frontend }
      toPorts:
        - ports: [{ port: "8080", protocol: TCP }]
          rules:
            http:                       # <-- ONLY this rule triggers node-Envoy parsing
              - method: "GET"
                path: "/v1/cart.*"

Practically, this makes Cilium the cheapest of the three sidecarless stories to run at L4 — there is, quite literally, no additional proxy process for L4-only traffic — at the cost of being the most tightly coupled to one specific CNI. You can't bolt Cilium's mesh onto a cluster running Calico or the AWS VPC CNI the way you could add Istio Ambient on top of most CNIs; the mesh capability is inseparable from the choice of CNI itself. The CCA blueprint's own "Service Mesh" domain — 16% of that exam — is built entirely around this sidecarless-by-construction model, alongside Cilium's Ingress and Gateway API support.

Where the operational cost actually lands

☺ Like you're 10: Every option here is a trade, not a free upgrade. Fewer guards means each guard covers more ground — great for cost, worse for you the one time a guard has a bad day.

Laid side by side, the four options this page has covered trade the same handful of costs against each other in different proportions: how many proxy processes exist, how much blast radius one failing proxy carries, how many extra hops a request takes, and how much of the mesh's own upgrade you have to coordinate yourself.

Deciding whether a mesh earns its keep

☺ Like you're 10: Not every building needs a security team at all. Some just need a good lock on the front door — adding guards you don't need just means paying guards to stand around.

None of the exams on this shelf ask whether you should run a mesh at all — they assume you already decided yes. In real platform work that decision comes first, and getting it wrong in either direction is expensive: adopting a mesh nobody needed adds a whole new distributed system's worth of upgrades, failure modes and 2 a.m. pages for capabilities a simpler setup already covered; skipping one that was actually needed leaves every team reinventing mTLS, retries and authorization inside their own application code, inconsistently, forever.

A mesh tends to earn its cost when several of these are true at once: you have enough services and enough teams that consistent mTLS and authorization can no longer be enforced by convention or code review; you need traffic-shifting or canary releases without redeploying application code every time a rollout strategy changes; a compliance or zero-trust requirement needs provable, enforced encryption-in-transit and identity-aware access, not a policy document; or you want golden-signal observability — latency, error rate, request volume — for every service without instrumenting each one by hand. It tends to not earn its cost when the service count is small enough that a handful of engineers already know every dependency by heart, when latency budgets are tight enough that even Cilium's near-zero L4 tax matters, or — the one people skip past — when nobody on the team has the bandwidth to actually own a control-plane upgrade cadence. A mesh that nobody upgrades for a year is not a safety net; it's an unpatched, unmonitored trust boundary sitting quietly in the middle of your traffic.