The service mesh Linkerd is now available in version 2.9. The project managed by the Cloud Native Computing Foundation (CNCF) introduces a multicore runtime in addition to ARM support.

On the way to Zero Trust Security Linkerd 2.9 extends the mTLS support (mutual TLS). This enables Linkerd to transparently encrypt and authenticate all TCP connections in the cluster at the moment of installation. So far, the service mesh only offered this for HTTP traffic. With the innovation, Linkerd should automatically encrypt and validate all TCP connections between the networked endpoints. This also includes the automatic rotation of the pod certificates every 24 hours and the automatic linking of the TLS identity to the pod’s Kubernetes ServiceAccount.

According to the announcement, this innovation is a big step towards zero trust security for Kubernetes users. With encryption and authentication to the pod boundary (the smallest execution unit in Kubernetes) Linkerd offers “encryption in transit” in a revised form. Future versions should expand the “Security-First Feature Set” with guidelines and enforcement based on the cryptographic identity and confidentiality guarantees of mTLS.

Upgrade to Multi-Core Runtime The current version of the service mesh is upgrading the proxy to a multi-core runtime in order to increase throughput and concurrency for individual pods. According to the blog post, Linkerd is known for its speed and low memory requirements compared to other service meshes such as Istio, which is probably due to the use of the “micro-proxy” written in Rust. Until now, the use of a single-core runtime was sufficient. The upgrade to a multi-core runtime should lead to further performance improvements, which the development team behind the service mesh would like to illustrate with benchmarks over the next few weeks.

In addition, the release offers ARM support, which should enable developers, for example, to reduce costs with ARM-based computing units such as AWS Graviton or to run Linkerd on a Raspberry Pi cluster. In addition, Linkerd 2.9 maintains support for service topology features from Kubernetes. This gives developers the opportunity to introduce routing preferences such as “Request should stay in this node” or “Request should stay in this region”. This in turn should lead to significant increases in performance and cost savings, especially for large applications.

What is a service mesh? The ability of a service mesh to simplify complex containers and improve network functions makes technology an important infrastructure layer. In a service mesh, each service instance is linked to that of a reverse proxy server. The service instance and the sidecar proxy share a container, which in turn is managed by a container orchestration tool. The service proxies are responsible for communication with other service instances and can support functions such as service detection, load balancing, authentication and authorization, and secure communication.

The service instances form the service mesh and your sidecar proxy is the data level, which also includes processing and answering queries. The service mesh also includes a level to control the interaction between the services, which is mediated by their sidecar proxies.

A complete overview There is a blog post about the new features in Linkerd 2.9 for publication. More details can be found in the release notes on GitHub.

(mdo)