Linkerd is a service mesh for Kubernetes. It places a small proxy beside each application pod and, through it, encrypts service-to-service traffic with mutual TLS, balances load per request, retries and times out failed calls, and reports success rate, latency and throughput for every meshed workload. It addresses the work teams otherwise repeat inside every service, or leave undone: secure internal traffic, reliable calls and consistent metrics across many microservices. Buoyant created Linkerd, and it was the first project to enter what the CNCF now calls the Sandbox; it graduated on July 28, 2021. The current Linkerd 2.x line, with a purpose-built Rust data plane proxy, was announced as version 2.20 on June 23, 2026.
CNCF daily · Sprint 2, day 3 · Service Mesh
At a glance
| Category | Service Mesh |
| CNCF status | Graduated. First project in the CNCF’s earliest tier; graduated July 28, 2021 |
| Written in | Rust (data plane proxy) and Go (control plane) |
| License | Apache 2.0 |
| Current release line | Linkerd 2.20 (announced June 23, 2026); edge releases continue weekly to monthly |
| Release model | Since February 2024 the open source project publishes edge releases only; stable releases come from vendors such as Buoyant (Buoyant Enterprise for Linkerd) |
| Data plane | linkerd2-proxy, a sidecar written in Rust for low memory and latency overhead |
Architecture
flowchart TB
CLI[linkerd CLI or Helm] -->|install| CP[Control plane<br/>linkerd namespace]
CP --> DEST[destination<br/>service discovery and policy]
CP --> ID[identity<br/>issues workload certificates]
CP --> INJ[proxy-injector<br/>adds sidecar at pod creation]
INJ --> P1[Pod A<br/>app and linkerd2-proxy]
INJ --> P2[Pod B<br/>app and linkerd2-proxy]
P1 -->|mutual TLS| P2
DEST -->|endpoints and policy| P1
ID -->|short-lived certificates| P1
ID -->|short-lived certificates| P2
P1 -->|golden metrics| PROM[Prometheus<br/>and Grafana]
P2 -->|golden metrics| PROM
TRUST[Trust anchor and issuer<br/>cert-manager or Vault] --> ID
| Component | Responsibility |
|---|---|
| linkerd2-proxy | Ultralight sidecar that intercepts pod traffic, adds mTLS, load balancing, retries and timeouts, and exposes metrics. |
| destination | Control plane service that tells proxies where endpoints are and which policies apply. |
| identity | Acts as a certificate authority for the mesh, issuing short-lived certificates tied to each workload’s service account. |
| proxy-injector | Admission webhook that adds the proxy container to pods in annotated namespaces. |
| Policy resources | Server, AuthorizationPolicy and HTTPRoute resources that restrict which identities may call which services and routes. |
| Viz extension | Optional metrics components and dashboard built on Prometheus, installed separately from the core mesh. |
Design principle. Linkerd aims to be the smallest mesh that provides the essentials, with sensible defaults. Mutual TLS is on by default for meshed TCP traffic, and the proxy is purpose-built rather than a general-purpose proxy, which keeps resource use and operational surface low.
Production reference design
A typical deployment on EKS, GKE, AKS or on-premises Kubernetes installs Linkerd through Helm with certificates managed by cert-manager, then meshes namespaces gradually.
- Create the trust anchor and issuer with cert-manager (a long-lived root held offline or in Vault, and an intermediate issuer that cert-manager rotates), so the mesh identity certificates renew automatically.
- Install the CRDs and control plane with Helm, pinning versions and passing the issuer certificate as
identity.issuervalues or via cert-manager:
Teams that need stable, supported releases typically install the vendor distribution, whose charts follow the same structure.helm repo add linkerd-edge https://helm.linkerd.io/edge helm repo update helm install linkerd-crds linkerd-edge/linkerd-crds -n linkerd --create-namespace helm install linkerd-control-plane linkerd-edge/linkerd-control-plane -n linkerd \ --set-file identityTrustAnchorsPEM=ca.crt \ --set identity.issuer.scheme=kubernetes.io/tls - Mesh a namespace by annotating it, then restart workloads so the injector adds proxies:
apiVersion: v1 kind: Namespace metadata: name: shop annotations: linkerd.io/inject: enabled - Restrict access by default and allow only what is needed, for example permitting only the
ordersservice account to call the payments server:apiVersion: policy.linkerd.io/v1beta1 kind: Server metadata: name: payments-http namespace: shop spec: podSelector: matchLabels: { app: payments } port: http proxyProtocol: HTTP/2 --- apiVersion: policy.linkerd.io/v1alpha1 kind: AuthorizationPolicy metadata: name: payments-from-orders namespace: shop spec: targetRef: group: policy.linkerd.io kind: Server name: payments-http requiredAuthenticationRefs: - name: orders-identity kind: MeshTLSAuthentication group: policy.linkerd.io - Observe and check: run
linkerd check, thenlinkerd viz stat deploy -n shopfor success rate, request rate and latency, and scrape proxy metrics into your own Prometheus and Grafana. - Roll out progressively, one namespace at a time, starting with stateless services and leaving databases and system namespaces unmeshed until tested.
Typical production uses are zero-trust service-to-service encryption, consistent golden-metric dashboards, retries and timeouts for flaky dependencies, and multi-cluster service communication.
Operational considerations
- Scaling: proxy memory and CPU scale with traffic and the number of endpoints; set proxy resource requests explicitly for busy pods. The 2.20 release reported lower control plane memory under high pod churn.
- High availability: install the control plane in HA mode, with multiple replicas spread across zones and PodDisruptionBudgets, because proxies depend on it for new endpoints and certificate renewal.
- Security: keep the trust anchor offline or in a secrets manager, rotate the issuer certificate before expiry, and apply authorization policies so identity is used for access control and not only encryption.
- Cost and sizing: every meshed pod adds a sidecar; budget the extra requests across the fleet. The proxy is small, but thousands of pods still add up.
- Common pitfalls: an expired issuer certificate (the most frequent outage), skipping the required restart after annotating a namespace, meshing jobs that never terminate because the sidecar keeps the pod alive, and assuming open-source stable releases still exist after the February 2024 change; plan how stable builds will be sourced.
Adoption
The Linkerd graduation announcement named Elkjøp, Entain, H-E-B, Microsoft and HP among organisations running Linkerd in production, and noted that Civo offers it in its marketplace. Buoyant offers a managed service and a supported enterprise distribution. Further users and case studies are published on the Linkerd website and on the CNCF project page.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Istio (CNCF Graduated) | Feature-rich mesh with sidecar and ambient modes | Large platforms needing broad traffic management and extensibility |
| Cilium Service Mesh (CNCF Graduated) | eBPF-based networking with mesh features | Teams already using Cilium for CNI and wanting fewer proxies |
| Consul (NON CNCF) | Service discovery and mesh across Kubernetes and VMs | Mixed Kubernetes and virtual machine estates |
| Cloud meshes (AWS App Mesh successors, Cloud Service Mesh on GKE) | Managed control plane | Teams preferring a provider-managed mesh |
| Application-level libraries (gRPC retries, mTLS in code) | No mesh | Few services and strong control over every codebase |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| Small, fast Rust proxy with low overhead | Smaller feature set than Istio, by design |
| mTLS enabled by default with automatic certificate rotation | Open source project publishes edge releases only; stable builds come from vendors |
| Simple installation and a short operational learning curve | Sidecars add resources per pod and a restart step to adopt |
| Strong golden metrics and tap-style debugging | Advanced traffic shifting and extensibility lag behind larger meshes |
| Graduated, vendor-neutral CNCF governance | Certificate lifecycle must be managed carefully |
Recommendation
Adopt Linkerd for teams that want service-to-service encryption, reliability and metrics with the least operational weight. Start with Helm, cert-manager-managed issuer certificates and a single non-critical namespace, add authorization policies once traffic is understood, and decide early how stable releases will be obtained. Teams needing very rich traffic management, VM support or sidecarless designs should compare Istio or Cilium first.
References: CNCF project page · Linkerd releases and versions · Linkerd graduation announcement · InfoQ: Linkerd 2.20 · Linkerd documentation