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.
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.
Linkerd is for everyone. In practice, Linkerd has certain technical prerequisites. Read on below.
The “d” is pronounced separately, i.e. “Linker-DEE”. (It’s a UNIX thing.)
Just like this: Linkerd. Capital “L”, lower-case everything else.
No. Everything in Linkerd is fully open source. Some companies provide commercial support for Linkerd.
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.
Yes, the 1.x branch of Linkerd is under active development, and continues to power the production infrastructure of companies around the globe.
Linkerd 2.x currently requires Kubernetes, though this will change in the future. Linkerd 1.x can be installed on any platform, and supports Kubernetes, DC/OS, Mesos, Consul, and ZooKeeper-based environments.
As a community project, there is no official roadmap. 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.
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.