Service Mesh Architecture Diagram: Istio, Cilium, and Linkerd (2026)

A service mesh architecture diagram visualizes the proxy layer that sits between microservices — handling mutual TLS (mTLS), traffic management, observability, and circuit breaking without changing application code. As Kubernetes adoption matures, service meshes like Istio, Cilium, and Linkerd have become standard platform engineering infrastructure. Diagramming your service mesh is essential for security reviews (mTLS policies), traffic engineering (canary deployments), and onboarding new platform engineers who need to understand how the mesh controls every byte of east-west traffic.

Unlike a standard microservices diagram, a service mesh diagram must expose the infrastructure layer that application developers rarely see directly: the sidecar proxies, the control plane issuing certificates, the policy objects shaping traffic, and the telemetry pipelines extracting traces and metrics. Without these elements, the diagram misrepresents how the system actually works.

The two planes of a service mesh

The most important conceptual split in any service mesh architecture diagram is the separation between the data plane and the control plane. Every service mesh, regardless of vendor, implements both.

Data plane

The data plane consists of the proxies that intercept all traffic flowing between services. In Istio, these are Envoy sidecars injected automatically into every pod by the Istio mutating webhook. In Linkerd, they are ultralight Rust micro-proxies with a minimal resource footprint. Cilium takes a fundamentally different approach: rather than sidecar proxies, it uses eBPF programs running at the Linux kernel level, bypassing the user-space proxy entirely. In your diagram, the data plane should appear as the layer closest to the service containers — every service box should show its proxy companion.

Control plane

The control plane manages proxy configuration, issues mTLS certificates, and enforces policies. For Istio, this is istiod running in the istio-system namespace — it combines Pilot (traffic management), Citadel (certificate authority), and Galley (config validation) into a single binary. Cilium uses the Cilium Operator to manage eBPF programs and CiliumNetworkPolicy enforcement. Linkerd runs a lightweight Linkerd control plane in the linkerd namespace. In your diagram, config flows downward: control plane → proxy sidecar (or eBPF hook) → service traffic.

Service mesh diagram prompt templates

These prompts are ready to paste into ArchitectureDiagram.ai to generate accurate service mesh architecture diagrams in seconds.

Basic Istio setup on Kubernetes

Canary deployment with traffic splitting

Cilium with eBPF networking

Multi-cluster mesh with Linkerd

Istio vs. Linkerd vs. Cilium: comparison

Choosing which service mesh to diagram — and diagram accurately — means understanding how each differs in architecture. This table maps the key dimensions.

What a service mesh architecture diagram must show

A service mesh diagram that only shows service boxes connected by arrows is missing most of what matters. A complete service mesh architecture diagram includes all of the following:

• Control plane location and components — istiod, Cilium Operator, or Linkerd control plane, with the namespace they run in. The control plane is as important as the data plane sidecars.
• mTLS boundary — which services are enrolled in the mesh (and therefore have mTLS enforced) versus external services or legacy workloads that are outside the mesh.
• Traffic policies — VirtualServices and DestinationRules for Istio, or equivalent objects for other meshes, showing routing weights, retries, timeouts, and circuit breaker configuration.
• Security policies — PeerAuthentication objects (enforcing mTLS mode: STRICT or PERMISSIVE) and AuthorizationPolicy objects (service-level RBAC) applied per namespace or per workload.
• Observability outputs — traces, metrics, and flow logs leaving the mesh: where Prometheus scrapes, where Jaeger or Zipkin receives spans, and where Hubble flow logs are sent.
• Ingress and egress gateways — the boundary between the mesh and the outside world. Istio IngressGateway and EgressGateway are separate components from the sidecar proxies and must be explicitly shown.

Common service mesh diagramming mistakes

Most service mesh architecture diagrams that reach engineering reviews or RFCs have at least one of these problems:

• Drawing only the service boxes with arrows between them and no proxy layer shown. This is a microservices diagram, not a service mesh diagram. The proxy sidecars — or eBPF hooks — are the entire point.
• Missing the control plane entirely — showing only the data plane sidecars without istiod or its equivalent omits the component responsible for certificate issuance, policy enforcement, and proxy configuration distribution.
• Not distinguishing east-west from north-south traffic — east-west (service-to-service within the cluster) and north-south (ingress from external clients and egress to external APIs) have different components handling them and must be visually separated.
• Omitting the certificate authority and cert rotation — mTLS is meaningless without showing how service identities are issued (SPIFFE/SPIRE, istiod's built-in CA, or an external CA like Vault). The cert rotation interval is relevant for security reviews.
• Not showing which namespaces are mesh-enrolled vs. excluded — most clusters have namespaces opted out of the mesh (kube-system, monitoring, the mesh control plane itself). These exclusions are important for security reviewers assessing the actual mTLS coverage.

Frequently asked questions

What is a service mesh architecture diagram?

A service mesh architecture diagram visualizes the proxy infrastructure layer that sits between microservices in a Kubernetes environment. It shows the data plane (sidecar proxies or eBPF programs intercepting traffic), the control plane (managing certificates and policies), mTLS boundaries, traffic routing rules, security policies, and observability outputs. Unlike a generic microservices diagram, a service mesh diagram exposes the infrastructure that enforces security and reliability without application-level changes.

Should I show Envoy sidecars in every service in my architecture diagram?

Yes — for Istio-based meshes, showing the Envoy sidecar next to every service pod is the single most important accuracy improvement you can make. Without it, the diagram looks like a plain microservices diagram and fails to communicate that the mesh is intercepting all service-to-service traffic. In practice, you can show a representative pod with a labeled "Envoy proxy" container alongside the app container, then indicate via a note that Istio injects this into all mesh-enrolled pods. For Cilium, replace the sidecar with an eBPF annotation at the node level, since there is no per-pod proxy.

What is the difference between Istio and Cilium in an architecture diagram?

The most visually significant difference is the proxy model. An Istio architecture diagram shows Envoy sidecar containers inside every pod, a dedicated istiod control plane in its own namespace, and Istio-specific CRDs (VirtualService, DestinationRule, PeerAuthentication). A Cilium architecture diagram shows no sidecars at all — instead, eBPF programs are attached at the kernel level on each node, the Cilium Operator manages policy, and Hubble provides the observability layer. The Cilium diagram looks significantly less cluttered at the pod level, while the Istio diagram exposes much more per-service policy granularity.

Related guides: Kubernetes architecture diagram examples, platform engineering diagrams, microservice architecture patterns, Kubernetes architecture use cases, platform engineering use cases, and observability architecture.