Skip to content
intermediate Phase 12 · Service Mesh

Linkerd Service Mesh

Implement Linkerd as a lightweight, CNCF-approved service mesh alternative.

1h
0 problems
Topic Progress 0%

Lightweight Mesh Architecture

Lightweight Mesh Architecture

Linkerd (CNCF) installs a small control plane — identity (certificate issuance), destination (service discovery for proxies), and proxy-injector — plus a Rust-based linkerd2-proxy sidecar in each pod. Unlike Istio, there is no Envoy and no large config surface: proxies get identity and service profiles from the control plane and keep routing tables simple.

Pre-check and install:

linkerd check --pre
linkerd install | kubectl apply -f -
linkerd check

The identity component mints per-workload certificates so mTLS is automatic between injected pods; traffic to un-injected pods simply stays plaintext until they join.

Injection and Viz

Injection and Viz

Opt a whole namespace in with an annotation, or inject a manifest on the fly:

kubectl label ns shop linkerd.io/inject=enabled --overwrite
linkerd inject deploy/checkout.yaml | kubectl apply -f -

For dashboards and live views install the viz extension, then read traffic:

linkerd viz install | kubectl apply -f -
linkerd viz stat deploy -n shop      # RPS, success rate, latency
linkerd viz top deploy -n shop       # live per-route throughput
linkerd viz edges deploy -n shop     # client → server graph
linkerd viz tap deploy/checkout -n shop

Success rate and p99 latency come straight from proxy-reported metrics — no application instrumentation required. ServiceProfile CRDs add per-route splitting and SLO-level stats for HTTP services.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Opaque ports. The proxy classifies traffic as HTTP/1, HTTP/2, or gRPC; anything else (MySQL, Redis, custom binary protocols) must be marked:

config.linkerd.io/opaque-ports: "3306"

Otherwise retries and metrics misbehave on protocols the proxy cannot parse.

Half-mesh confusion. Expecting mTLS where a pod was never injected yields plaintext — confirm with linkerd viz edges (meshed/unmeshed) before debugging policy.

Trust rotation. The trust root and issuer certificates rotate independently; plan rotation before expiry (the dashboard and linkerd check surface it).

Interview angle: contrast with Istio — Rust proxy instead of Envoy, fewer CRDs, faster install — and say when you would still choose Istio (advanced traffic shaping, Envoy extensibility, gateways ecosystem).

Quiz

1. What proxy does Linkerd use in the data plane?

Question 1 options

2. How do you opt a namespace into Linkerd?

Question 2 options

3. Why mark a MySQL port as opaque?

Question 3 options

Flashcards

Question

Linkerd control plane pieces

Answer

identity (certs), destination (service discovery for proxies), proxy-injector — plus viz extension for dashboards.

Question

linkerd inject

Answer

Renders a manifest with the proxy sidecar added, ready to pipe into kubectl apply.

Question

Opaque ports

Answer

config.linkerd.io/opaque-ports annotation marking non-HTTP protocols for raw TCP handling.

Question

linkerd viz stat

Answer

Per-workload RPS, success rate, and latency straight from proxy metrics.

Revision Notes

Key Takeaways

  • 1. Linkerd = small control plane + Rust proxies; mTLS and telemetry come free on injected pods
  • 2. Opt in via namespace label or linkerd inject; observe with viz stat/top/edges
  • 3. Opaque ports and mesh coverage are the classic operational gotchas

Interview Tips

  • • Compare Linkerd and Istio on data plane, config surface, and when you would pick each
  • • Show how you verify mesh coverage and mTLS status with concrete commands

Cheat Sheet

linkerd check --pre → install → label ns linkerd.io/inject=enabled. viz stat/top/edges for success rate + latency. Opaque ports for non-HTTP. Rust proxy vs Istio's Envoy.

Continue Learning