Skip to content

Portal | Level: L3: Advanced | Topics: Service Mesh | Domain: Kubernetes

Service Mesh - Skill Check

Mental model (bottom-up)

A service mesh is a sidecar proxy per pod that handles mTLS, retries, traffic splitting, and observability without app changes. A control plane configures all proxies.

Visual stack

[App Container   ]  your code, unchanged
|
[Sidecar Proxy   ]  Envoy (Istio) or linkerd2-proxy (Linkerd)
|
[Control Plane   ]  Istiod / Linkerd control - configures proxies, issues certs
|
[Data Plane      ]  all proxies form the mesh network

Glossary

  • sidecar proxy - container injected alongside app to intercept all traffic
  • mTLS - mutual TLS; both sides present certificates for encryption + identity
  • data plane - the set of all sidecar proxies handling traffic
  • control plane - manages proxy configuration and certificate issuance
  • VirtualService - Istio CRD for routing rules (traffic splits, retries, faults)
  • DestinationRule - Istio CRD for backend policies (subsets, load balancing)
  • TrafficSplit - SMI CRD used by Linkerd for canary traffic weighting

Core questions (easy -> hard)

  • What problem does a service mesh solve?
  • Cross-cutting concerns (encryption, retries, observability) without app changes.
  • How does sidecar injection work?
  • Mutating admission webhook adds proxy container to pods automatically.
  • How does mTLS work in a mesh?
  • Control plane is CA, issues short-lived certs to each proxy, auto-rotated.
  • Istio vs Linkerd tradeoffs?
  • Istio: more features, heavier (Envoy ~100MB). Linkerd: simpler, lighter (Rust ~20MB).
  • What happens when the control plane goes down?
  • Data plane continues with last-known config. Cert rotation eventually fails.
  • How do you do canary deployments with a mesh?
  • Traffic split CRD (SMI) or VirtualService (Istio) with weighted routing.

Wiki Navigation

Prerequisites

Related Content