Frequently Asked Questions

What is Linkerd?

Linkerd is a service mesh. It adds observability, reliability, and security to cloud native applications without requiring code changes. For example, Linkerd can monitor and report per-service success rates and latencies, can automatically retry failed requests, and can encrypt and validate connections between services, all without requiring any modification of the application itself.

Linkerd works by inserting ultralight proxies (collectively, the “data plane”) alongside each application instance. Linkerd’s control plane provides operators with a uniform point at which they can control and measure the behavior of the data plane. Operators typically interact with Linkerd using the CLI and the web dashboard UI.

What’s the difference between Linkerd and Istio?

Linkerd and Istio are both service meshes. While the two projects share similar goals, there are some significant design differences:

  1. Linkerd is focused on simplicity, speed, and low resource usage. It is significantly smaller and faster than Istio, though it currently has fewer features.

  2. Linkerd is built for security from the ground up, ranging from feature like on-by-default mTLS, a data plane that is built in a memory-safe language, and regular security audits.

  3. Linkerd is committed to open governance and is hosted by a neutral foundation. Istio is primarily controlled by Google.

Of course, the choice of which service mesh to use depends on the specifics of the situation. Both Linkerd and Istio operate at the cluster level, and so it’s possible (and not unheard of) to run both within the same organization.

What’s the difference between Linkerd and Envoy?

Envoy is a proxy, not a service mesh. Linkerd is a service mesh: it has a control plane and a data plane, and the data plane is implemented with proxies. Envoy can be used as a component of a service mesh, but Linkerd uses a different proxy, simply called linkerd2-proxy.

Why doesn’t Linkerd use Envoy?

Envoy is a general-purpose proxy. By using linkerd2-proxy, which is built specifically for the service mesh sidecar use case, Linkerd can be significantly smaller and faster than Envoy-based service meshes. Additionally, the choice of Rust for linkerd2-proxy allows Linkerd to avoid a whole class of CVEs and vulnerabilities that can impact proxies written in non-memory-safe languages like C++—a critical requirement for security-focused projects like Linkerd.

Who owns Linkerd and how is it licensed?

Linkerd is hosted by the Cloud Native Computing Foundation (CNCF) project. The CNCF owns the trademark; the copyright is held by the Linkerd authors themselves.

Linkerd is licensed under Apache 2.0.

Who is Linkerd for?

Linkerd is for everyone—see Linkerd’s Commitment to Open Governance. In practice, Linkerd has certain technical prerequisites, such as Kubernetes.

How do I pronounce Linkerd?

The “d” is pronounced separately, i.e. “Linker-DEE”. (It’s a UNIX thing.)

How do I write Linkerd?

Just like this: Linkerd. Capital “L”, lower-case everything else.

Who maintains Linkerd?

See the 2.x maintainers file, and the 1.x maintainers file.

Is there an Enterprise edition, or a commercial edition?

Linkerd is fully open source. Some companies provide commercial packages or support for Linkerd.

What’s the difference between Linkerd 1.x and 2.x?

Linkerd 1.x is built on the “Twitter stack”: Finagle, Netty, Scala, and the JVM.

Linkerd 2.x is built in Rust and Go. It is significantly faster and lighter weight than 1.x, but currently only supports Kubernetes.

Is Linkerd 1.x still supported?

Yes, the 1.x branch of Linkerd is under active development, and continues to power the production infrastructure of companies around the globe.

The full Linkerd 1.x documentation is here.

Does Linkerd require Kubernetes?

Linkerd 2.x currently requires Kubernetes. Linkerd 1.x can be installed on any platform, and supports Kubernetes, DC/OS, Mesos, Consul, and ZooKeeper-based environments.

Where’s the Linkerd roadmap?

As a community project, there is no formal roadmap, but a glance at the active GitHub issues will give you a sense of what is in store for the future.

The public Linkerd Meetup slides also provides a coarse-grained roadmap.

How secure is Linkerd?

Very secure. A third party security audit of Linkerd 2.x was completed in June 2019, and Linkerd passed with flying colors.

How fast is Linkerd?

Very fast. A third party performance evaluation of Linkerd vs Istio was performed in May of 2019, and showed that Linkerd significantly outperformed Istio.

How do I use Linkerd to route traffic between services?

(2.x) Linkerd doesn’t change the way routing works. You address other services just as you would without Linkerd, e.g. service-name.namespace.svc.cluster.local, or service-name if within the same namespace.

How does Linkerd handle ingress?

(2.x) For reasons of simplicity, Linkerd doesn’t provide ingress itself, but instead works in conjunction with the ingress controller of your choice.

What happens to Linkerd’s proxies if the control plane is down?

Linkerd’s proxies do not integrate with Kubernetes directly, but rely on the control plane for service discovery information. The proxies are designed to continue operating even if they can’t reach the control plane.

If the control plane dies, existing proxies will continue to operate with the latest service discovery information. If Additionally, they will fall back to DNS if asked to route to a service they don’t have information for. (Thus, if the control plane is down, but new services are created, you may notice different load balancing behavior until the control plane resumes.) Once the control plane is functional, the Linkerd proxies will resume communication as normal.

If new proxies are deployed when the control plane is unreachable, these new proxies will not be able to operate. They will timeout all new requests until such time as they can reach the control plane.

How do I get involved?

See our Linkerd Community page!