Data Plane, Control Plane
Data Plane, Control Plane
A Kubernetes Service gives L4 load balancing, DNS, and nothing else: no per-route rules, no encryption by default, no latency histograms. A service mesh moves cross-cutting networking logic out of application code:
- Data plane: an Envoy (or Linkerd's Rust proxy) sidecar per pod, proxying every inbound/outbound connection
- Control plane: distributes configuration (routes, policies, certificates) to proxies and reports telemetry
The application talks to localhost; the proxy intercepts traffic transparently. That is what lets teams add mTLS, retries, and canaries without redeploying code.
Identity and mTLS
Identity and mTLS
Mesh identity is cryptographic, derived from the pod's ServiceAccount:
spiffe://cluster.local/ns/payments/sa/api
The control plane issues short-lived certificates (commonly via SPIFFE-compatible CA workflows) and rotates them automatically. Authorization policies then say "only ns/frontend may call ns/api on port 8080" — identity-based, not IP-based.
PeerAuthentication modes control enforcement: PERMISSIVE accepts plaintext and mesh traffic (useful during rollout), STRICT rejects anything without mesh identity. Telemetry flows alongside: per-route request counts, latency histograms, and trace context propagated via standard headers.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Cost of sidecars. Every pod gains a proxy container: extra memory/CPU per replica, an extra container to drain on termination, and a new failure surface when the proxy hangs.
Protocol assumptions. Meshes classify traffic as HTTP/gRPC/TCP — misdeclared ports (common with databases or custom protocols) break routing and metrics until marked opaque or excluded.
Localhost breaks. Pods relying on sidecar-free localhost or host networking need exclusion annotations, or traffic loops.
When not to. If you need only mTLS, consider pluggable encryption; a full mesh pays off when you want L7 traffic control, uniform observability, and multi-cluster policy.
Interview angle: name the two planes, the identity scheme, and one concrete feature you get for free versus hand-rolling in each service.
Quiz
1. What do sidecar proxies in a mesh actually do?
2. What is PeerAuthentication STRICT mode for?
3. What is a real cost of the sidecar model?
Flashcards
Question
Mesh data plane vs control plane
Click to reveal answer
Answer
Data plane = per-pod proxies forwarding traffic; control plane = pushes config/certs and collects telemetry.
Question
SPIFFE identity in-mesh
Click to reveal answer
Answer
URI like spiffe://cluster.local/ns/<ns>/sa/<sa> — cryptographic workload identity from the ServiceAccount.
Question
PERMISSIVE vs STRICT mTLS
Click to reveal answer
Answer
PERMISSIVE accepts plaintext and mesh traffic (migration); STRICT requires mesh identity for all traffic.
Question
What a mesh adds over Services
Click to reveal answer
Answer
L7 routing, mTLS, retries/timeouts, traffic splitting, and per-route telemetry without app changes.
Revision Notes
Key Takeaways
- 1. Meshes split concerns: proxies enforce, control planes configure, apps keep talking to localhost
- 2. Identity comes from ServiceAccounts, certificates rotate, policies are identity-based
- 3. Sidecar overhead and protocol classification are the honest costs to weigh against the benefits
Interview Tips
- • Name the planes and walk one request through client proxy → control-plane config → server proxy
- • State a concrete case where you would decline a mesh and what you would do instead
Cheat Sheet
Mesh = sidecar data plane + control plane (config/certs/telemetry). Identity spiffe://cluster.local/ns/x/sa/y; PERMISSIVE→STRICT for mTLS. Adds L7 routing, retries, metrics; costs overhead.
Continue Learning
Before You Start
- No prerequisites listed.