Linkerd 2.17 introduces three major new features to the project: egress traffic visibility and control; per-service rate limiting; and federated services, a powerful new multi-cluster primitive which combines services running in multiple clusters into a single logical service.

Linkerd 2.17 is is one of the first Linkerd releases in years to introduce multiple significant features at once.

Egress visibility and control: Linkerd 2.17 introduces visibility and control for egress traffic leaving the Kubernetes cluster from meshed pods. Kubernetes itself provides no mechanisms for understanding egress traffic, and only rudimentary ones for restricting it (limited to IP ranges and ports). With the 2.17 release, Linkerd now gives you full L7 (application-layer) visibility and control of all egress traffic: you can view the source, destination, and traffic levels of all traffic leaving your cluster, including the hostnames (and with configuration, the full HTTP paths or gRPC methods). You also can deploy egress security policies that allow or disallow that traffic with that same level of granularity, allowing you to allowlist or blocklist egress by DNS domain rather than IP range and port.

Linkerd’s egress functionality does not require changes from the application and only minimal configuration to get started. For more advanced usage, egress configuration is built on Gateway API resources, allowing you to configure egress visibility and policies with the same extensible and Kubernetes-native configuration primitives used for almost every other aspect of Linkerd, including dynamic traffic routing, zero trust authorization policies, and more.

Rate limiting is a reliability mechanism that protects services from being overloaded. In contrast to Linkerd’s circuit breaking feature, which is client-side behavior designed to protect clients from failing servivces, rate limiting is server-side behavior: it is enforced by the service receiving the traffic and designed to protect it from misbehaving clients.

Just as with egress, Linkerd’s rate limiting feature is designed to require as minimal configuration as possible.

Federated services: Linkerd 2.17 includes an exciting new multicluster feature: federated services. A federated service is a union of the replicas of the same service across multiple clusters. Meshed clients talking to a federated service will automatically load balance across all endpoints in all clusters, taking full advantage of Linkerd’s best-in-class latency-aware load balancing. This means that not only is application code decoupled from cluster deployment decisions—Foo talking to Bar needs only to call Bar, not to specify which cluster(s) it is on—but failure handling is transparent and automatic as well. If a cluster is down entirely, or the service on that cluster is down, or failing in any way; Linkerd will load balance across other endpoints; if a cluster is distant, slow, or the service is bogged down, Linkerd’s latency-aware load balancing will prefer other endpoints; and so on.

This new feature was designed to capture recent trends we see in multicluster Kubernetes adoption. Linkerd’s original multicluster usage (released in the good old days of Linkerd 2.8) was for the ad-hoc, pair-to-pair multicluster usage that was common at the time. However, more modern Kubernetes platforms are largely planned multi-cluster, with hundreds or thousands of clusters and replicating services across all of them. Federated services join features such as flat network / pod-to-pod multicluster (introduced in Linkerd 2.14) to support this new approach.