Design Principles

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

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

Finally, just work means that adding Linkerd to a functioning Kubernetes application shouldn’t break anything, and shouldn’t even require configuration. (Of course, configuration will be necessary to customize Linkerd’s behavior–but it shouldn’t be necessary simply to get things working.) To do this, we’ve invested heavily in things like automatic L7 protocol detection, and .

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