Design Principles

Linkerd is built for you, the operator, SRE, architect, and platform owner.It’s designed to give you power over your own fate: to provide fundamentalvisibility, reliability, and security capabilities at the platform level. Thegoal of Linkerd is to give you these powers in a way that’s uniform across allcode running in the entire compute environment, and totally independent ofapplication code or developer teams.

Since Linkerd is built for operators, this also means that Linkerd has do allthat while also imposing the absolute minimum operational complexity. To dothis, we’ve designed Linkerd with three core principles in mind:

  • Keep it simple. Linkerd should be operationally simple with lowcognitive overhead. Operators should find its components clear and its behaviorunderstandable and predictable, with a minimum of magic.

  • Minimize resource requirements. Linkerd should impose as minimal aperformance and resource cost as possible–especially at the data plane layer.

  • Just work. Linkerd should not break existing applications, nor should itrequire complex configuration to get started or to do something simple.

The first principle is the most important: keep it simple. Simplicity doesn’tmean that Linkerd can’t have powerful features, or that it has to haveone-click wizards take care of everything for you. In fact, it means theopposite: every aspect of Linkerd’s behavior should be explicit, clear,well-defined, bounded, understandable, and introspectable. For example,Linkerd’s control plane is splitinto several operational components based on their functional boundaries(“web”, “api”, etc.) These components aren’t just exposed directly to you inthe Linkerd dashboard and CLI, they run on the same data plane as yourapplication does, allowing you to use the same tooling to inspect theirbehavior.

Minimize resource requirements means that Linkerd, and especially Linkerd’sdata plane proxies, should consume thesmallest amount of memory and CPU possible. On the control plane side, we’vetaken care to ensure that components scale gracefully in the presence oftraffic. On the data plane side, we’ve build Linkerd’s proxy (called simply“linkerd-proxy”) for performance, safety, and low resource consumption. Today,a single linkerd-proxy instance can proxy many thousands of requests per secondin under 10mb of memory and a quarter of a core, all with a p99 tail latency ofunder 1ms. In the future, we can probably improve even that!

Finally, just work means that adding Linkerd to a functioning Kubernetesapplication shouldn’t break anything, and shouldn’t even require configuration.(Of course, configuration will be necessary to customize Linkerd’sbehavior–but it shouldn’t be necessary simply to get things working.) To dothis, we’ve invested heavily in things like automatic L7 protocoldetection, and automatic re-routing of TCPtraffic within a pod.

Together, these three principles give us a framework for weighing product andengineering tradeoffs in Linkerd. We hope they’re also useful for understandingwhy Linkerd works the way it does.