- Frequently Asked Questions
- What is Linkerd?
- What’s the difference between Linkerd and Istio?
- What’s the difference between Linkerd and Envoy?
- Why doesn’t Linkerd use Envoy?
- Who owns Linkerd and how is it licensed?
- Who created Linkerd?
- Who is Linkerd for?
- How do I pronounce Linkerd?
- How do I write Linkerd?
- Is there a Linkerd “enterprise edition”?
- Can I get commercial support?
- What’s on the Linkerd roadmap?
- Can I present Linkerd to my team / company / meetup group?
- How do I use Linkerd to route traffic between services?
- Does Linkerd handle ingress traffic?
- What happens to Linkerd’s proxies if the control plane is down?
- What CPU architectures can Linkerd run on?
- How can I get involved?
Frequently Asked Questions
What is Linkerd?
Linkerd is a service mesh. It adds observability, reliability, and security to Kubernetes applications without 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.
What’s the difference between Linkerd and Istio?
Linkerd is significantly lighter and simpler than Istio. Linkerd is built for security from the ground up, ranging from features like on-by-default mTLS, a data plane that is built in a Rust, memory-safe language, and regular security audits. Finally, Linkerd has publicly committed to open governance and is hosted by the CNCF.
What’s the difference between Linkerd and Envoy?
Envoy is a proxy; Linkerd is a service mesh. Linkerd has a control plane and a data plane, and uses a proxy is a component of the data plane. While Envoy can be used as a component of a service mesh, Linkerd uses an ultralight “micro-proxy” called Linkerd2-proxy, which is built in Rust for safety and performance.
Why doesn’t Linkerd use Envoy?
Envoy is a complex general-purpose proxy. Linkerd uses a simple and ultralight “micro-proxy” called Linkerd2-proxy that is built specifically for the service mesh sidecar use case. This allows Linkerd to be significantly smaller and simpler than Envoy-based service meshes. The choice of Rust also allows Linkerd to avoid a whole class of CVEs and vulnerabilities that can impact proxies written in non-memory-safe languages like C++. See Why Linkerd doesn’t use Envoy for more.
Who owns Linkerd and how is it licensed?
Linkerd is hosted by the Cloud Native Computing Foundation (CNCF). The CNCF owns the trademark; the copyright is held by the Linkerd authors themselves. Linkerd is licensed under the Apache 2.0 license.
Who created Linkerd?
Linkerd was originally created by Buoyant. Buoyant continues to be a sponsor of the project and to provid commercial support.
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?
Linkerd rhymes with “Cardi B”. The “d” is pronounced separately, as in “Linker-DEE”.
How do I write Linkerd?
Just like this: Linkerd. Capital “L”, lower-case everything else.
Is there a Linkerd “enterprise edition”?
No. Linkerd is fully open source with everything you need to run it in production as part of the open source project.
Can I get commercial support?
Yes. See the list of companies that provide commercial support for Linkerd.
What’s on the Linkerd roadmap?
See the Linkerd project roadmap. You may also review the active GitHub issues for shorter-term objectives.
Can I present Linkerd to my team / company / meetup group?
Certainly! The public Linkerd meetup slides might be helpful.
How do I use Linkerd to route traffic between services?
Linkerd is designed to be fully transparent. 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.
Does Linkerd handle ingress traffic?
No. 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. 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.
What CPU architectures can Linkerd run on?
Linkerd uses multi-arch container images with support for x86, amd64, arm64, and arm.
How can I get involved?
We’d love to have you get involved! See our Linkerd Community page.