Linkerd 2.x: a Kubernetes service mesh you install with one CLI command

What Linkerd 2.x adds to a Kubernetes cluster

The README describes Linkerd as an ultralight, security-first service mesh for Kubernetes, and says it adds security, observability and reliability features with no code change required. That last phrase is the whole pitch. Instead of putting retry logic, mutual TLS and request metrics into each service, you let the mesh handle them between pods. The audience is platform and infrastructure teams running Kubernetes who want those features without asking application developers to rewrite clients or link a language-specific SDK. Linkerd is a CNCF project, and the README points to the Getting Started Guide for install instructions rather than embedding them, which is a deliberate split: this repository is the control plane and CLI, not the documentation site.

Control plane in Go, data plane in Rust, split across repositories

The README lists the Linkerd repositories explicitly. linkerd2 is the main 2.x repo and contains the control plane and CLI. linkerd2-proxy is the data plane proxy, and linkerd2-proxy-api holds the gRPC API bindings between them. That separation is visible in the repository itself: the top level has Go files (go.mod, cli/, controller/, pkg/, viz/, multicluster/) and Rust files (Cargo.toml, Cargo.lock, rust-toolchain.toml, policy-controller/, policy-test/). The Cargo workspace members are all policy-controller crates plus policy-test, so the Rust side in this repo is the policy controller, not the proxy. The proxy version is pinned by a top-level .proxy-version file, which means the control plane and data plane are versioned independently and the pin is what keeps them compatible. The Go module depends on github.com/linkerd/linkerd2-proxy-api v0.20.0, and the Cargo workspace depends on linkerd2-proxy-api 0.20.0 with the inbound and outbound features. Both languages therefore meet at the same generated gRPC surface. The justfile confirms the two toolchains: go-fetch, go-fmt, go-lint and go-test on one side, rs-fetch, rs-fmt, rs-clippy and rs-test on the other, with a combined lint target that runs both.

Installing Linkerd and running the first check

The README does not include install commands. It says you can run Linkerd on any modern Kubernetes cluster in a matter of seconds and points to the Linkerd Getting Started Guide at linkerd.io/2/getting-started/ for how. That guide is where the CLI download, the install step and the verification step live, so treat this repository as the source of the binaries rather than the instructions. What the repository does tell you is what you will be running once the guide is done. The CLI lives in cli/, the control plane in controller/, the Helm charts in charts/, and the policy controller in policy-controller/. If you build from source instead of using a release, the justfile is the entry point for the Go side:

go mod download
golangci-lint run
LINKERD_TEST_PRETTY_DIFF=1 gotestsum --jsonfile go-test.json -- -race -v -mod=readonly --timeout 10m ./...

Those three targets come from the justfile's go-fetch, go-lint and go-test recipes. The test command writes a JSON report and runs with the race detector, so expect a slow first run. For the Rust side, the justfile defines rs-fetch and rs-test, and the Cargo workspace pins its dependencies through Cargo.lock, so rs-fetch runs with --locked. The release profile in Cargo.toml sets lto to thin, which is a build-time choice that trades compile time for a smaller binary. None of this is a substitute for the Getting Started Guide; it is what you need if you are contributing to or building the control plane rather than just installing it.

The policy controller is a second control plane component

Most introductions to Linkerd stop at the proxy and the CLI. This repository carries something else: a Rust policy controller with its own workspace members for core, grpc, k8s/api, k8s/index, k8s/status and runtime. The Cargo.toml pins k8s-openapi to the v1_33 feature and kube to 3.1 with default features off, and it pulls kubert from a git tag rather than crates.io. That is a meaningful operational detail. A git dependency on a tagged revision means the build resolves kubert from GitHub, so an air-gapped build environment needs a vendored or mirrored copy. The policy controller also has its own test crate, linkerd-policy-test, which the rs-test recipe excludes from the normal workspace test run, implying it is exercised separately. If you are evaluating Linkerd for a regulated environment, the policy controller is the component to read first, because authorization policy is where the security claims actually get enforced.

Where Linkerd 2.x is the wrong tool

The README scopes Linkerd to Kubernetes, and says you can run it on any modern Kubernetes cluster. That is also the boundary. If your services run on virtual machines, on bare metal outside a cluster, or on a scheduler that is not Kubernetes, this repository does not address that case; the mesh is built around Kubernetes APIs, custom resources and the control plane's own deployment. A second limitation is the split between repositories. The proxy that actually handles traffic is not in this repo, so reading linkerd2 alone will not tell you how the data plane behaves under load, how it handles connection pooling, or what its failure modes are. You have to follow .proxy-version to linkerd2-proxy for that. A third is the Rust build chain. Building the policy controller requires cargo and the toolchain pinned in rust-toolchain.toml, and the Cargo.toml depends on kubert from a git tag, so a build environment that only allows crates.io will need extra work. None of this is a defect; it is the cost of a design that keeps the data plane small and separate.

Linkerd compared with Istio and Cilium

The two comparisons people search for most are Linkerd versus Istio and Linkerd versus Cilium, and the difference in approach is structural rather than a feature checklist. Istio historically ships a larger control plane with its own proxy and a broader configuration surface, including a sidecar and ambient mode; Linkerd's README positions the project as ultralight, which is a claim about the data plane footprint rather than about the control plane. Cilium is a CNI plugin first, with mesh capabilities layered onto eBPF networking at the kernel level. That is a different insertion point: Cilium operates in the network stack, Linkerd operates with a proxy alongside the pod. The practical consequence is that Cilium's mesh features are tied to Cilium being your CNI, while Linkerd's proxy model works with the CNI you already run. This repository does not benchmark itself against either project, and the README makes no performance comparison, so treat the ultralight label as a design statement from the project rather than a measured result.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-21. Recent releases are edge builds: edge-26.9.3 on 2026-09-16, edge-26.9.2 on 2026-09-15 and edge-26.9.1 on 2026-09-04. The edge naming matters for upgrade planning, because it signals a faster-moving channel than a stable line, and the README does not document a rollback procedure for a mesh upgrade. The Go module targets go 1.26.7 and pins Kubernetes libraries at v0.37.0 across api, apimachinery, client-go, code-generator and endpointslice, so a cluster upgrade path has to be checked against those pins. The Rust side pins k8s-openapi to the v1_33 feature. Licence is Apache-2.0, stated in the README and in the LICENSE file. Apache-2.0 includes an express patent grant and requires that you preserve notices and state changes; it does not grant trademark rights, and the README does not describe a separate trademark policy. This is a description of the licence text, not legal advice. The README also notes that Linkerd undergoes periodic third-party security audits and publishes the results in the audits/ directory, which is the concrete artifact to review before a security-sensitive rollout.

Editorial conclusion

Adopt Linkerd 2.x if you run a modern Kubernetes cluster and want mutual TLS, traffic metrics and retries without touching application code, and you accept that the proxy is a separate Rust artifact pinned by .proxy-version. Do not adopt it if you need a mesh that covers non-Kubernetes workloads or if you cannot run the policy controller alongside the rest of the control plane. Before rolling it out, read the Getting Started Guide, check the audits/ directory for the published third-party security audit results, and confirm which Kubernetes versions your cluster runs against the k8s.io libraries pinned in go.mod.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. linkerd/linkerd2 on GitHub
3. Project website
4. README
5. Releases