From 18deefb9fb8d5a5f592aed53490fe0bf41948ec8 Mon Sep 17 00:00:00 2001 From: Travis Beckham Date: Fri, 12 Apr 2024 11:10:49 -0500 Subject: [PATCH] Lint Signed-off-by: Travis Beckham --- linkerd.io/content/2.15/tasks/upgrade.md | 1 - .../content/design-principles/_index.md | 55 ++++++++++--------- linkerd.io/content/releases/_index.md | 10 ++-- 3 files changed, 33 insertions(+), 33 deletions(-) diff --git a/linkerd.io/content/2.15/tasks/upgrade.md b/linkerd.io/content/2.15/tasks/upgrade.md index ef3ee6bdac..9b66adb6a7 100644 --- a/linkerd.io/content/2.15/tasks/upgrade.md +++ b/linkerd.io/content/2.15/tasks/upgrade.md @@ -636,4 +636,3 @@ dropped, moving the config values underneath it into the root scope. Any values you had customized there will need to be migrated; in particular `identityTrustAnchorsPEM` in order to conserve the value you set during install." - diff --git a/linkerd.io/content/design-principles/_index.md b/linkerd.io/content/design-principles/_index.md index 73538fcc47..49ce8a8eb4 100644 --- a/linkerd.io/content/design-principles/_index.md +++ b/linkerd.io/content/design-principles/_index.md @@ -3,8 +3,8 @@ title = "Design Principles" weight = 19 +++ -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 fundamental +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 fundamental visibility, reliability, and security capabilities at the platform level. The goal of Linkerd is to give you these powers in a way that's uniform across all code running in the entire compute environment, and totally independent of @@ -14,44 +14,45 @@ 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: -1. **Keep it simple**. Linkerd should be operationally simple with low -cognitive overhead. Operators should find its components clear and its behavior -understandable and predictable, with a minimum of magic. +1. **Keep it simple**. Linkerd should be operationally simple with low cognitive + overhead. Operators should find its components clear and its behavior + understandable and predictable, with a minimum of magic. 2. **Minimize resource requirements**. Linkerd should impose as minimal a -performance and resource cost as possible--especially at the data plane layer. + performance and resource cost as possible--especially at the data plane + layer. 3. **Just work**. Linkerd should not break existing applications, nor should it -require complex configuration to get started or to do something simple. + require complex configuration to get started or to do something simple. 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 [control plane](/2/reference/architecture/#control-plane) 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. +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 +[control plane](/2/reference/architecture/#control-plane) 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. _Minimize resource requirements_ means that Linkerd, and especially Linkerd's -[data plane proxies](/2/reference/architecture/#data-plane), should consume the smallest amount of -memory and CPU possible. On the control plane side, we've taken care to ensure -that components scale gracefully in the presence of traffic. 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 second in under 10mb of memory -and a quarter of a core, all with a p99 tail latency of under 1ms. In the -future, we can probably improve even that! +[data plane proxies](/2/reference/architecture/#data-plane), should consume the +smallest amount of memory and CPU possible. On the control plane side, we've +taken care to ensure that components scale gracefully in the presence of +traffic. 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 second in +under 10mb of memory and a quarter of a core, all with a p99 tail latency of +under 1ms. In the future, we can probably improve even that! 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](/2/features/protocol-detection/), and [automatic re-routing of TCP -traffic within a pod](/2/features/proxy-injection/). +invested heavily in things like +[automatic L7 protocol detection](/2/features/protocol-detection/), and +[automatic re-routing of TCP traffic within a pod](/2/features/proxy-injection/). Together, these three principles give us a framework for weighing product and engineering tradeoffs in Linkerd. We hope they're also useful for understanding diff --git a/linkerd.io/content/releases/_index.md b/linkerd.io/content/releases/_index.md index 98b149c51d..a44d8d0480 100644 --- a/linkerd.io/content/releases/_index.md +++ b/linkerd.io/content/releases/_index.md @@ -24,6 +24,7 @@ The full list of edge release artifacts can be found on [the Linkerd GitHub releases page](https://github.com/linkerd/linkerd2/releases). + Latest version: **{{% latestedge %}}** [[release notes](https://github.com/linkerd/linkerd2/releases/tag/{{% latestedge %}})]. @@ -35,8 +36,7 @@ responsible for supported, stable release artifacts. Known distributions of Linkerd with stable release artifacts include: -* [Buoyant Enterprise for - Linkerd](https://docs.buoyant.io/buoyant-enterprise-linkerd) from Buoyant, - creators of Linkerd.
Latest version: - **enterprise-2.15.2** [[release - notes](https://docs.buoyant.io/release-notes/buoyant-enterprise-linkerd/enterprise-2.15.2/)]. +- [Buoyant Enterprise for Linkerd](https://docs.buoyant.io/buoyant-enterprise-linkerd) + from Buoyant, creators of Linkerd. + Latest version: **enterprise-2.15.2** + [[release notes](https://docs.buoyant.io/release-notes/buoyant-enterprise-linkerd/enterprise-2.15.2/)].