linkerd service mesh

Linkerd: Looming on Service Meshes

by | 12.09.2021 | Engineering

Microservices and service meshes have become a staple of the industry as companies realize the full potential of creating an independent architecture that allows for easier scale up, agile development, resilience and streamlined deployment. Many of these applications are interfaced and communicated with through lightweight APIs that allow users, companies and stakeholders to avoid the pitfalls of a monolithic system.

One of the latest talks of the town surrounds the Linkerd service mesh that boasts an ultralight palette of services for Kubernetes. But before you go about adopting this service mesh on your mesh, let’s take a deeper dive into its hits and misses. And for the purpose of semantics, Linkerd is pronounced as “Linker-DEE”.

A Top Down Look at Linkerd

Linkerd as a service mesh is designed to remove the challenges of running services by integrating components for critical security, observability and reliability, all built as a Cloud Native Computing Foundation graduate project.

At the same time, it also integrates these features into the mainframe without requiring users to implement serious code changes to repositories, thus improving deployment and communication.

Linkerd Service Mesh
Linkerd Service Mesh Source: Linkerd

Being an open source application released under the Apache v2 license, it’s important to dissect and understand the various components that makes Linkerd such an interesting choice among the plethora of service mesh software.


Components and Functions

Linkerd possesses three basic components:

  1. A UI interface with application icons, connection interfaces and platform apps.
  2. A data plane that allows users to connect with native data apps, perform import/export functions and so on.
  3. A control plane to execute commands for backend changes, regulating information flow, app communication and other application edits.
Linkerd Components Interface:

Linkerd Components Interface: Container Journal

Linkerd works quite simply with an installation of Kubernetes, the CLI and the control panel separately. Since Linkerd echoes the same implementations as a microservice like Istio service mesh, all components and apps run independently from each other. Linkerd installs a series of transparent proxies next to each service instance. All the installed proxies handle traffic that comes in and out of the services. The layer of transparency in this case creates a network of stacks that send telemetry information from the control plane.

The control plane is composed of controller components, including a web component that links with an administrative dashboard and a metrics component. The panel also supports modified versions of Prometheus and Grafana. The data plane too uses its own proxy which puts it at an advantage compared to data planes in other microservices like Envoy.


Protocols and Languages

Linkerd 2.x currently supports HTTP 1.1, HTTP2, gRPC, and TCP communication between services via their sidecar proxies. It does not however support TCP connections.

Implementation Languages

Linkerd 2.x is exclusively written in Go. Linkerd’s proxy for its data plane runs on Rust and allows for multifunction compatibility with all types of data analytical softwares and platforms. It should be noted that Linkerd 1.x was written in Scala originally.

Service Mesh Sidecar Architecture
Service Mesh Sidecar Architecture Source: Platform9

Where Linkerd Shines

Being a service mesh application written after industry names like Istio and Consul, Linkerd carries on from many of the traditions of older mesh systems while bringing its own unique take on services.

Sidecar Injection

Sidecars can be added and deployed through artifacts by using the service mesh control plane. Users can now natively add these automatically to applications with no changed code complications.

High Availability

Feature availability for Linkerd were still in the experimental state in previous versions but can now be implemented with additional capabilities to make applications far more useful. Users can now make apps available for online and cloud based pipelines with reduced challenges of server crashes or telemetry load limits.

Monitoring and Tracing Support

Linkerd currently supports Prometheus and Grafana for monitoring out of the box applications but still lacks distributed tracing.

….And Everything Else

But these are just some of the known merits that Linkerd holds. While Istio may be quite difficult to set up in the cluster, Linkerd requires no configuration as it works out of the box and can be scaled horizontally with ease.

Apart from the protocols and languages seen above, it also supports TLS application wide. The service mesh is highly intelligent and distributes traffic using modern load-balancing algorithms, allowing users to send requests dynamically and shift traffic as required.

Configuring the root cause of failures is also easier since the system supports distributed tracing and aligns perfectly with present day microservices. Users can also have total awareness about the state of the system by looking at dashboards to assess real time performances, including operations connected to Prometheus and Grafana.


Where Linkerd Falls Short and Final Thoughts 🥱

Criticisms regarding Linkerd have usually been aimed at the comparatively large memory footprint, which prompted the community to shift focus on the development of Conduit, a lightweight service mesh specifically for Kubernetes, written in Rust and Go. The Conduit project is seen as a subsidiary to Linkerd and has since been folded into the mainframe. Linkerd was thus relaunched as Linkerd 2.0 in July of 2018.

Users still face issues of telemetry rate limiting if hosting multiple applications, which creates the need for another application to deal with overloading traffic. Linkerd also runs on a per-host deployment model. This introduces another common problem where a single proxy failure can affect multiple services. This still doesn’t remedy the relatively high resource requirements of Linkerd 1.x and its future renditions.

For users planning on applying Linkerd on their applications, it is best recommended to run Linkerd using Sidecar pattern, along with every pod but will still plague the systems with heavy resource usages. Users would thus best benefit to run it per node.

It’s best to have every Linkerd pod with one or more instances of all services such that all nodes in the network are able to communicate with each other. Using a NoSQL platform like DataStax or Cassandra can fix this to avoid direct Service-to-Service communication across the neighbouring nodes.

As a general piece of advice, Linkerd proxies should be allowed to talk to another Linkerd proxy. Additionally, users should create alerts based on Prometheus or Grafana metrics of running applications provided by proxies. It is best if it is for some of the Microservices first before the applications are injected for the entire network.

Follow back on the blog to learn more about upcoming technologies and how to implement the best strategies for your projects.

PS: We admire the work of the developer community. Do connect with the team and give us a shoutout on social media. Feel free to reach out to us if you want us to help you with a service mesh implementation 😉

Happy Learning!

CommunityNew

The DevOps Awareness Program

Subscribe to the newsletter

Join 100+ cloud native ethusiasts

#wearep3r

Join the community Slack

Discuss all things Kubernetes, DevOps and Cloud Native

Related articles6

Introduction to GitOps

Introduction to GitOps

GitOps serves to make the process of development and operations more developer-centric. It applies DevOps practices with Git as a single source of truth for infrastructure automation and deployment, hence the name “Git Ops.” But before getting deeper into what is...

Kaniko: How Users Can Make The Best Use of Docker

Kaniko: How Users Can Make The Best Use of Docker

Whether you love or hate containers, there are only a handful of ways to work with them properly that ensures proper application use with Docker. While there do exist a handful of solutions on the web and on the cloud to deal with all the needs that come with running...

Cilium: A Beginner’s Guide To Improve Security

Cilium: A Beginner’s Guide To Improve Security

A continuation from the previous series on eBPF and security concerns; it cannot be reiterated enough number of times how important it is for developers to ensure the safety and security of their applications. With the ever expanding reach of cloud and software...

How to clean up disk space occupied by Docker images?

How to clean up disk space occupied by Docker images?

Docker has revolutionised containers even if they weren't the first to walk the path of containerisation. The ease and agility docker provide makes it the preferred engine to explore for any beginner or enterprise looking towards containers. The one problem most of...

Parsing Packages with Porter

Parsing Packages with Porter

Porter works as a containerized tool that helps users to package the elements of any existing application or codebase along with client tools, configuration resources and deployment logic in a single bundle. This bundle can be further moved, exported, shared and distributed with just simple commands.

eBPF – The Next Frontier In Linux (Introduction)

eBPF – The Next Frontier In Linux (Introduction)

The three great giants of the operating system even today are well regarded as Linux, Windows and Mac OS. But when it comes to creating all purpose and open source applications, Linux still takes the reign as a crucial piece of a developer’s toolkit. However, you...