Announcing Buoyant Enterprise for Linkerd 2.20: Automated trust anchor rotation, Windows VM support, rate-limit-aware load balancing, and more

Buoyant Enterprise for Linkerd 2.20 is now available! This release automates rotation of mTLS trust anchors; adds support for Windows VMs running outside of Kubernetes; and improves circuit breaking and load balancing (including zone-aware HAZL balancing) to be aware of rate-limited services. Linkerd 2.20 also improves memory consumption of the control plane, especially on busy clusters, and promotes native sidecars to the default deployment type for Linkerd’s data plane microproxies.

If you’re interested in a technical deep dive on this release, keep an eye out for our upcoming Service Mesh Academy workshops: on July 18 we’ll cover automated trust anchor rotation, and on August 20 we’ll walk through Windows VM support. 

With this release, Linkerd extends its support for Windows containers to VMs, becoming the first service mesh to provide official support for Windows applications running outside of Kubernetes. As usual, this is just the latest in a long list of firsts for Linkerd—the first service mesh; the project to coin the term itself; and the first service mesh to achieve graduated status in the CNCF.

Linkerd has now seen almost a decade of continuous improvement and evolution. Our goal is to build a service mesh that our users can rely on for 100 years. We partner with customers like Expel and IntelliGRC to seamlessly expand workloads across cloud providers and to meet strict federal security requirements with FIPS-validated encryption of data in transit.

Linkerd 2.20 is the fourth major version since the announcement of Buoyant's profitability and Linkerd project sustainability, and continues our laser focus on operational simplicity: delivering the notoriously complex service mesh feature set in a way that is manageable, scalable, and performant.

Automated trust anchor rotation

Linkerd is designed to never fail. Linkerd is also designed to never allow untrusted communication. Unfortunately, if the TLS infrastructure that Linkerd uses for authentication is misconfigured, these two behaviors are at odds. The results of TLS misconfiguration at the root level can be especially catastrophic: in the worst case, a complete refusal to communicate between any meshed pods.

In practice, the most common cause of TLS misconfiguration is the process of trust anchor rotation, a delicate operation that updates, in place, the global root of trust across all clusters and pods in a system handling live traffic. A misstep in this process can result in this catastrophic scenario.

To prevent these situations, Linkerd 2.20 introduces a new trust anchor rotation operator. This component fully automates trust anchor rotation, placing all the necessary guardrails in place to ensure this process happens safely. If your security environment requires rotating your TLS trust anchor, we highly recommend letting the operator take care of this process for you.

Windows VM support

As of Linkerd 2.20, Linkerd’s ultra-light Rust microproxies can now run on Windows VMs outside of Kubernetes, allowing non-containerized Windows applications to join the mesh and take full advantage of Linkerd’s full suite of reliability, observability, and security features, including mutual TLS, retries and timeouts, circuit breaking, and multicluster communication.

In keeping with Linkerd’s goal of delivering the full power of the service mesh with maximum simplicity, meshing your Windows applications with Linkerd is as simple as running the native installer on Windows Server 2022 or 2025 either in interactive or silent mode, and providing the port information of the application to mesh. Windows applications on this host will now be meshed by Linkerd, and all TCP traffic to and from these applications automatically made observable, reliable, and secure.

Rate-limit-aware load balancing and circuit breaking

Since its inception, one of Linkerd’s most powerful features has been its latency-aware load balancing. When distributing individual HTTP or gRPC requests across endpoints, this algorithm weights available endpoints by the exponentially-weighted moving average (EWMA) of their latency—allowing it to react quickly to latency spikes—and automatically favors endpoints that are currently responding the quickest. Load balancing is often paired with another powerful client-side feature, circuit breaking, which automatically ejects endpoints that return too many 5xx error responses, preventing Linkerd from sending traffic to endpoints that are failing, even if they’re failing quickly!

In this release, we’ve extended the logic of both load balancing and circuit breaking to handle rate-limited services that return HTTP 429 (or gRPC RESOURCE_EXHAUSTED) responses. These services aren’t failing, per se, but they are explicitly signaling that they aren’t able to handle more traffic. (Note that these responses may even originate from Linkerd’s rate-limiting feature running on the service!)

Linkerd can now be configured to respect these response codes, biasing traffic away from overloaded endpoints or even removing them entirely from the pool.

Control plane memory improvements

Linkerd’s control plane is the component responsible for, among many other things, reflecting the state of the Kubernetes clusters in such a way that Linkerd’s data plane microproxies are up-to-date. One critical part of the control plane is the destination controller, which maintains a map of everything on the cluster that a meshed pod might be asked to talk to.

Because it needs to model the state of the cluster, the destination controller is typically responsible for the majority of Linkerd’s control plane memory usage, especially in high-scale environments. In Linkerd 2.20, we’ve refactored the destination controller to optimize its internal state management, cutting memory usage in some cases by almost 85%. Linkerd users in large or fast-moving clusters with lots of pod churn should notice a dramatic improvement in Linkerd’s memory consumption. 

Proxy metrics, tracing, and OpenTelemetry improvements

Linkerd provides a rich set of metrics for all traffic it sees, especially if that traffic is HTTP (including gRPC). This includes metrics around request latencies, success rates, and much more.

Historically, these metrics have focused on the “outbound” side of Linkerd: traffic that leaves the pod. In Linkerd 2.20 we’ve greatly improved the set of metrics available for the inbound side of Linkerd (traffic entering the pod), and brought them up to near parity with the outbound side. This includes new metrics for the volume and statuses of inbound requests, as well as new histograms tracking the distribution of request and response durations and frame sizes (tracked separately for HTTP and gRPC traffic).

In designing these new metrics, we’ve also continued improving Linkerd’s compliance with OpenTelemetry semantic conventions as well as making sure distributed tracing spans get sent to OpenTelemetry regularly, so that operators can better reason about the traffic on their clusters.

Other fun stuff

Linkerd 2.20 brings our maximum supported Kubernetes versions up to 1.35 and max supported Gateway API version up to 1.5.1.

Linkerd 2.20 also promotes native sidecar support to stable and makes it the default for proxy injection. Native sidecars fix some of the long-standing annoyances of using sidecar containers in Kubernetes, especially around support for Jobs and race conditions around container startup. Support for native sidecars was first introduced in Linkerd 2.15, promoted to beta in 2.19, and has seen extensive use in production.

A full changelog is available on docs.buoyant.io. 

Getting your hands on Linkerd 2.20

The official stable release package of Buoyant Enterprise for Linkerd, BEL 2.20.0, is now available, as is our comprehensive changelog and upgrade guidance for existing Linkerd users. BEL is free for anyone to download and use in non-production environments, and free for companies with fewer than 50 employees to run in production. BEL is the version of Linkerd that we run in our own production systems, and you can get started with BEL in under five minutes.

‍