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.
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:
- A UI interface with application icons, connection interfaces and platform apps.
- A data plane that allows users to connect with native data apps, perform import/export functions and so on.
- A control plane to execute commands for backend changes, regulating information flow, app communication and other application edits.
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.
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.
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.
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.
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 😉