Over the past 18 months, the adoption of Linkerd has skyrocketed in enterprise environments, with companies like Adidas, Microsoft, Plaid, and DB Schenker deploying Linkerd to bring security, compliance, and reliability to their mission-critical production infrastructure. Today, we’re happy to announce the release of Linkerd 2.14 with improved support for multi-cluster deployments on shared flat networks, full Gateway API conformance, and much more.
The 2.14 release comes just four months after our massive Linkerd 2.13 release with circuit breaking and dynamic request routing, and continues Linkerd’s focus on coupling enterprise-grade power and flexibility with the best operational model simplicity and lowest TCO of any service mesh.
This release includes a lot of hard work from 25+ contributors. A special thank you to Amir Karimi, Amit Kumar, Andre Marcelo-Tanner, Andrew, Arnaud Beun, Clement, Dima, Grégoire Bellon-Gervais, Harsh Soni, Jean-Charles Legras, Loong Dai, Mark Robinson, Miguel Elias dos Santos, Pranoy Kumar Kundu, Ryan Hristovski, Takumi Sue, Zakhar Bessarab, hiteshwani29, pheianox, and pssalman for all your hard work!
Multi-cluster support for shared flat networks
Linkerd 2.14 introduces improved multi-cluster support for clusters deployed on a shared flat network. Increasingly common in enterprise environments, this network architecture allows pods in different clusters to establish TCP connections with each other. Linkerd takes advantage of this ability to add a new “gateway-less” mode for cross-cluster communication. In this mode, Linkerd establishes cross-cluster connections across clusters without transiting a multi-cluster gateway. This improves performance by reducing the latency of cross-cluster calls; it improves security by preserving workload identity in mTLS calls across clusters; and it reduces cloud spend by reducing the amount of traffic that is routed through the multi-cluster gateway.
Of course, Linkerd ensures that these cross-cluster connections are established with all the same guarantees as in-cluster connections: they are fully transparent to the application with the same security, reliability, and observability capabilities, including encryption, authentication, and zero-trust-capable authorization policies. This mode is also purely additive, and in heterogeneous network environments where flat networks are not possible, Linkerd’s existing gateway-based approach functions as normal.
Importantly, this new multi-cluster support retains a critical aspect to Linkerd’s design: independence of clusters as a way of isolating security and failure domains. Each cluster runs its own Linkerd control plane, and the failure of a single cluster cannot take down the service mesh on other clusters. (And Linkerd provides a set of powerful techniques including cross-cluster failover that can be used to automatically route traffic to the remaining clusters.)
For more details on Linkerd’s new support for multi-cluster across flat networks, see Enterprise multi-cluster at scale: supporting flat networks in Linkerd.
Gateway API conformance
Starting way back in the Linkerd 2.12 release, Linkerd has been on the forefront of adopting Kubernetes’s new Gateway API as the core configuration mechanism for Linkerd, including for features such as zero trust authorization policy and dynamic request routing. Adopting the Gateway API has a whole host of benefits for users, from providing standardized mechanisms for configuring complex resources such as classes of HTTP requests to providing a uniform API across ingress and service meshes to—most importantly for Linkerd’s philosophy of minimalism—reduction of additional configuration surface area, since the Gateway configuration resources that already live on the cluster.
In the Linkerd 2.14 release we’re happy to report that Linkerd is now fully conformant with the mesh profile of the Gateway API. This means that Linkerd now uses the core gateway.networking.k8s.io types, and that features like retries, timeouts, and progressive delivery are now fully configurable via these types without the requirement to use the earlier ServiceProfile resources.
The Linkerd team has been co-leading the GAMMA initiative to adapt the Gateway API to service mesh use cases, and we’re looking forward to watching this standard evolve over time.
And lots more!
Linkerd 2.14 also has a tremendous list of other improvements, performance enhancements, and bug fixes, including:
- A new
-o jsonflag for the linkerd multicluster gateways command
- A new
logFormatvalue to the multicluster Link Helm Chart (thanks @bunnybilou!)
- New leader-election capabilities to the service-mirror controller
- A new high-availability (HA) mode for the multicluster service-mirror
- A new
- A fix for missing route_ metrics for requests with ServiceProfiles
- A fix for proxy startup failure when using the
linkerd diagnostics policycommand now displays outbound policy when the target resource is a Service
- A fix for HA validation checks when Linkerd is installed with Helm.
- A fix for the
linkerd viz checkcommand so that it will wait until the viz extension becomes ready
- A new
-o jsonpathflag to linkerd viz tap to allow filtering output fields
- Tolerations and nodeSelector support in extensions namespace-metadata Jobs
- Build improvements for multi-arch build artifacts. Thanks @MarkSRobinson!!
And more. See the full release notes for details.
Last year was a banner year for Linkerd—the number of stable Kubernetes clusters running Linkerd doubled in 2022, and the project gained multi-cluster failover and full L7 authorization policy based on the Gateway API. In 2023, with Linkerd 2.13 and 2.14 already under our belts, we’re off to a great pace. We have some amazing features and ideas up our sleeves that we can’t wait to unveil later this year. Stay tuned!
Linkerd is for everyone
Linkerd is a graduated project of the Cloud Native Computing Foundation. Linkerd is committed to open governance. If you have feature requests, questions, or comments, we’d love to have you join our rapidly-growing community! Linkerd is hosted on GitHub, and we have a thriving community on Slack, Twitter, and the mailing lists. Come and join the fun!