Skip to content
intermediate Phase 12 · Service Mesh

Service Mesh Concepts

Learn core service mesh concepts including mTLS, observability, and traffic control.

45m
0 problems
Topic Progress 0%

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?

Question 1 options

2. What is PeerAuthentication STRICT mode for?

Question 2 options

3. What is a real cost of the sidecar model?

Question 3 options

Flashcards

Question

Mesh data plane vs control plane

Answer

Data plane = per-pod proxies forwarding traffic; control plane = pushes config/certs and collects telemetry.

Question

SPIFFE identity in-mesh

Answer

URI like spiffe://cluster.local/ns/<ns>/sa/<sa> — cryptographic workload identity from the ServiceAccount.

Question

PERMISSIVE vs STRICT mTLS

Answer

PERMISSIVE accepts plaintext and mesh traffic (migration); STRICT requires mesh identity for all traffic.

Question

What a mesh adds over Services

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.

Next Topics