Linkerd
Summary
- Linkerd is a lightweight, CNCF-graduated service mesh that prioritizes simplicity, automatic mTLS, and golden metrics over a large feature surface.
- Insight: Its data plane uses a purpose-built Rust micro-proxy rather than a general L7 proxy, which keeps per-pod memory and latency low.
- Key Concepts: control plane (identity, destination, proxy-injector), linkerd-proxy (the Rust sidecar), linkerd viz (metrics extension), automatic mTLS, service profiles and HTTPRoute.
- When to Use: you want mTLS and consistent success-rate/latency metrics quickly, with minimal operational burden.
- Limitations: fewer advanced traffic-management knobs than Istio; some features live in extensions you install separately.
- Related Topics: Istio, mTLS, golden metrics, the mesh-versus-no-mesh decision.
Recipe
The shortest path to a meshed workload with mTLS and metrics.
# 1. Install the CLI and validate the cluster
curl -fsSL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin
linkerd check --pre
# 2. Install CRDs, then the control plane
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
linkerd check
# 3. Add the metrics extension
linkerd viz install | kubectl apply -f -Then annotate a namespace for injection and restart its workloads.
kubectl annotate namespace payments linkerd.io/inject=enabled
kubectl rollout restart deploy -n paymentsWorking Example
A minimal Deployment plus namespace, meshed and observable.
apiVersion: v1
kind: Namespace
metadata:
name: payments
annotations:
linkerd.io/inject: enabled
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
namespace: payments
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
securityContext:
runAsNonRoot: true
containers:
- name: web
image: registry.example.com/web@sha256:abc123
ports:
- containerPort: 8080
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
memory: 256Mi
readinessProbe:
httpGet:
path: /healthz
port: 8080Apply it, then confirm the mesh is working.
kubectl apply -f web.yaml
linkerd viz stat deploy -n payments
linkerd viz edges deploy -n paymentsstat shows success rate, requests per second, and latency percentiles; edges confirms which connections are mTLS-secured.
Deep Dive
How the data plane works
Linkerd injects a Rust proxy (linkerd-proxy) as a sidecar container plus an init container that programs iptables to redirect traffic through it.
The proxy is deliberately small and single-purpose, which is why its memory footprint and tail latency are lower than a general-purpose L7 proxy.
Traffic between two meshed pods is transparently upgraded to mTLS by the proxies, with no application changes.
How identity works
The control plane's identity component acts as a certificate authority, issuing short-lived certificates tied to each pod's Kubernetes ServiceAccount.
Certificates rotate automatically (by default roughly every 24 hours), so there are no long-lived secrets to manage in the data path.
You should still plan trust-anchor rotation for the root certificate, which has a longer lifetime.
Golden metrics and routing
The linkerd viz extension collects the golden metrics - success rate, request volume, and latency - and ships a Prometheus and dashboard bundle.
For L7 routing Linkerd supports the Gateway API HTTPRoute, letting you split traffic by weight or match on paths and headers.
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: reviews-split
namespace: payments
spec:
parentRefs:
- name: reviews
kind: Service
group: core
rules:
- backendRefs:
- name: reviews-v1
port: 80
weight: 90
- name: reviews-v2
port: 80
weight: 10This shifts ten percent of reviews traffic to v2 for a canary without redeploying either version.
Gotchas
Injection is admission-time only, so annotating a namespace does nothing to pods already running - you must restart them.
If linkerd check fails on certificates, your trust anchor or issuer certificate likely expired; monitor expiry and rotate ahead of time.
The bundled Prometheus in linkerd viz is sized for demos and is not durable - point Linkerd at your own long-term Prometheus in production.
Meshing a namespace that includes the Kubernetes API or DNS pods can cause bootstrapping problems; keep system namespaces out of the mesh.
Upgrading Linkerd across a minor version means re-injecting workloads, which is a rolling restart across the fleet - schedule it.
Meshing a workload that opens raw TCP connections on unusual ports can require protocol hints, since the proxy infers HTTP by default.
If a pod fails to start after injection, check that the proxy-init container had the privileges it needs to program iptables, or use the CNI plugin variant to avoid init-container privileges entirely.
Alternatives
Istio offers a far larger traffic-management and policy surface, plus an ambient (sidecar-less) mode; pick it when you need advanced L7 control or want to avoid per-pod sidecars.
Cilium's mesh capabilities lean on eBPF at the node level and may suit teams already standardized on Cilium as their CNI.
For mTLS alone without a mesh, cert-manager or SPIRE with application TLS can be enough at small scale.
If you only need L3/L4 isolation, NetworkPolicy plus Ingress is simpler than any mesh.
FAQs
Is Linkerd lighter than Istio?
Generally yes. Its Rust micro-proxy is purpose-built and typically uses less memory and adds less tail latency than a general L7 proxy in sidecar mode.
Does Linkerd give me automatic mTLS?
Yes. Between meshed pods, mTLS is on by default with automatic certificate issuance and rotation, no configuration required.
Where do the metrics come from?
From the linkerd viz extension, which scrapes the proxies and exposes Prometheus metrics and a dashboard.
Does Linkerd use Docker on my nodes?
No. You may build images with Docker or BuildKit, but pods and their proxies run under containerd via the CRI.
Can I do canary deploys with Linkerd?
Yes, using Gateway API HTTPRoute weights, often driven by a progressive-delivery tool that gates on Linkerd's success-rate metrics.
Related
- What a Service Mesh Adds - and Costs
- Service Mesh Basics
- Istio
- Mesh vs No-Mesh ADR
- Service Mesh Best Practices
Stack versions: This page was written for Kubernetes 1.36.2, Docker Engine 29.6.1 (BuildKit default), containerd (CRI runtime on nodes), Helm 3, Compose v2, Argo CD (latest - verify at build), and Gateway API (GA - verify controller support at build).