Day 15: Service Mesh Concepts

Phase 3 · Jul 15, 2026

Agenda (2–3 hours)

• Read (45 min): Buoyant "What Is a Service Mesh?" blog post; Envoy proxy architecture documentation
• Study (45 min): Draw the data plane vs control plane architecture; map each piece to a concrete component (Envoy, istiod, Pilot)
• Practice (45 min): Install Istio on a local k3s/minikube cluster; deploy two services and observe the sidecar injection
• Challenge (30 min): What does "zero-trust networking" mean in a service mesh context? How does mTLS enforcement differ from just having a firewall?

The Service Mesh Problem

As the number of services grows, each service needs:

• Retries, timeouts, circuit breakers
• mTLS between services
• Distributed tracing
• Rate limiting
• Traffic routing (canaries, A/B tests)

Without a mesh: embed all this in every service (Tower middleware). Updating policies means redeploying every service. Language heterogeneity is a problem.

Service mesh solution: move network concerns into a sidecar proxy alongside each service.

Data Plane vs Control Plane

Data plane: the proxy sidecars (Envoy) that sit on every network connection

• Intercepts all traffic in/out of each pod/container
• Enforces policies: mTLS, retries, circuit breaking, load balancing
• Emits telemetry: traces, metrics, access logs

Control plane: the management layer (istiod in Istio)

• Configures all data plane proxies via xDS APIs
• Manages certificate lifecycle (Citadel component)
• Distributes routing rules, rate limits, and policies

Sidecar Pattern

Pod:
┌─────────────────────────────────┐
│  [Service Container]            │
│      ↓ localhost:8080           │
│  [Envoy Sidecar]                │
│      ↓ network                  │
│  iptables rules intercept all   │
│  ingress + egress traffic       │
└─────────────────────────────────┘

iptables rules (injected at pod startup via istio-init container) redirect all traffic through Envoy. The service container is unaware — it still binds to 0.0.0.0:8080.

This is the "transparent proxy" model: applications require zero code changes.

Envoy Proxy

Envoy is the data plane proxy used by Istio, AWS App Mesh, Consul Connect, and others.

Key concepts:

• Listener: binds to a port; handles incoming connections
• Filter chain: per-listener pipeline (HTTP filter, gRPC transcoder, RBAC, etc.)
• Cluster: upstream service + load balancing policy
• Route: map incoming request to a cluster (based on headers, path, weights)
• Endpoint: individual backend instance (health-checked, load-balanced)

Envoy is configured via xDS (discovery service) APIs — updated dynamically without restart.

Key Takeaways

• Service mesh moves cross-cutting concerns (mTLS, retries, observability) out of service code
• Data plane (Envoy sidecars) enforces policy; control plane (istiod) distributes policy
• Sidecar injection is transparent — applications don't need changes
• Envoy's xDS API allows real-time policy updates across the entire mesh

Tomorrow: Envoy xDS API — how the control plane programs the data plane.