Today we are pleased to announce that Linkerd 2.8 has been officially released! The new version of Linkerd introduces a multi-cluster extension mechanism, enabling it to connect across Kubernetes clusters, ensuring security and transparency for each cluster, and working with any network topology. We believe that this multi-cluster extension mechanism is currently the best option for secure multi-cluster connections in Kubernetes. In addition, version 2.8 also introduced an Add-On system for Linkerd to further enhance its modularity. Several other features and stability improvements were also introduced.

1. Implementation of multi-cluster Kubernetes in the way of Kubernetes

The new multi-cluster capability of Linkerd 2.8 means that Linkerd can now access various Kubernetes services across cluster boundaries in a way that is secure, fully transparent to the application, and independent of the network topology. This multi-clustering capability is designed to meet the following core objectives:

1. Provide a unified trust domain. The identity of the source and target workloads must be verified at each step within and across cluster boundaries.

2. Separate the fault domain. When one cluster goes down, the others should still be up and running.

3. Support heterogeneous network. Because clusters can span different cloud environments, VPCs, local data centers, and combinations, LINKERD should not introduce any L3/L4 requirements other than gateway connections.

4. Provide a unified model with intra-cluster communication capabilities. The observability, reliability, and security that Linkerd brings to intra-cluster communication will also be extended to new cross-cluster communication systems.

As with intra-cluster connections, Linkerd’s cross-cluster connections are also completely transparent to the application code. For example, service A on cluster west can directly address service C on cluster east to the form of C. ast for direct communication; Or it can be automatically addressed to C. ast and the service traffic is automatically routed (or even partially routed) to cluster C by Linkerd. Whether the traffic occurs within the same cluster, across multiple clusters within the same data center or VPC, or across the public Internet, Linkerd establishes connections between clusters and performs encryption and authentication at both ends via MTLS.

This new multi-clustering capability unlocks a number of use cases for Linkerd, including failover (moving traffic across the data center or cloud in the event of a failure); “Reverse multi-tenancy” (each tenant has its own cluster); Hybrid clouds (where workloads can be moved back and forth between local and cloud environments without affecting the rest of the application), and so on.

Finally, as with Linkerd’s other features, the multi-cluster “service mirroring” solution takes full advantage of existing Kubernetes capabilities and minimizes the involvement of additional components. Remote services will be represented directly as Kubernetes services, without introducing any new CRD, and configuration complexity will continue to be kept to a minimum.

2Ambassador supports multi-cluster solutions

We also want to announce that the Ambassador project development team has created a multi-cluster integration that allows users to use Ambassador deployments as a multi-cluster gateway to Linkerd! For more details, visit the Ambassador Project blog [1].

3 the plugin

Version 2.8 introduces a simple Add-On system for adding (or removing) functionality from Linkerd. Linkerd 2.8 comes with two plugins:

◾Jaeger plug-in for adding Jaeger and OC-Collector components designed to collect and display distributed trace results for a cluster.

◾Grafana Plugin (enabled by default) for adding Grafana diagrams to the Linkerd dashboard. In the future, we will continue to offer more features as plugins. For example, you can remove the default Prometheus installation and use another tool that you specify.

4 And more

Linkerd 2.8 also brings many other improvements, performance enhancements, and bug fixes, including:

◾ With the new Prometheus configuration option, the flexibility and modularity of HELM charts will be improved.

The ◾ agent now uses POD metadata to mark the distributed trace range that is issued.

◾ has made several performance improvements to the agent aimed at reducing contention, improving latency, and reducing pseudo timeouts.

◾ Automatically prevents common traffic cycle scenarios.

For more details, see the complete release notes [2].

Subsequent development roadmap of the 5LINKERD project

We believe that the core value of Linkerd is connectivity — in the cloud native world, connectivity means not just “A and B can exchange packets,” but “A and B can verify each other’s identities and exchange packets.” In other words, there are clear authorization semantics, confidentiality from third parties, and the entire process is fully measurable and verifiable.

Going forward, we believe Linkerd can achieve this connectivity and translate it into a secure plane suitable for Kubernetes usage scenarios. With the release of version 2.8, Linkerd has taken another big step in this direction. In the next few releases, we will continue to flesh out the Linkerd feature set, including extending MTLS to all connections, introducing new policies, and more. We’re still working on it, so stay tuned!

6 Use it now!

Ready to try Linkerd? We have released the latest version to some users in the weekly release of the experimental version. Of course, you can also run the following command to get a stable version 2.8:

1

curl https://run.linkerd.io/install | sh