Linkerd: Service Mesh Overview
Tags: linkerd, mesh, kubernetes, fundamentals
Published: 2020-11-19 05:37:26

Linkerd is a ultralight, ultrafast, security-first service mesh for Kubernetes.

Linkerd Service Mesh comes to solve the problem to add 3 layers at Cloud-Native Kubernetes app:
- Observability
- Security
- Reliability

Going back in monolith time, we have to deal with one language technology stack(for example: Java). And 3 operations teams to interact, deploy, operate with it: Devs, Networking and Security.

But if we look at a Cloud-Native Kubernetes app, we have multi-language and architecture scenarios. So, the chalengers are most complex, and add Observability, Security Layer and Reliability becomes a implementation and operations difficult task. 

On earliest 2010 years, Twitter, Netflix and Google dealt with this situations making native languages libraries for their microservices stacks. 

Twitter has evolved its jvm based library Finable to deal with a multilanguage architecture. Then changed the name to Linkerd on 2016. Became the first Service Mesh Plataform.  

In 2017 Linkerd was donated to CNCF.

In 2018 was launched the Linkerd 2.0 version. With several changes. Now we have a Linkerd2-proxy Rust-based and Control Plane Golang-based. 

Implement a network of proxies that communicate securely(mTLS) using HTTP and gRPC. It was the solution found to inject the mesh layer. Each microservice meshed has a proxy injected like a side-car container. 

The name of the proxies network layer is Data Plane. This is the base of collected metrics and active operations. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kugzn5aje8q3wmaml8t7.png)
<figcaption>Data Plane
</figcaption>

The other module is the Control Plane. This is the Linkerd Plataform Owners API Operations interface. Can be access by CLI or Browser. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/kihnxc72kbd6igb9mdug.png)
<figcaption>Linkerd 2.x Architecture
</figcaption>

Linkerd Features:
- Observability: Service-level golden metrics: success rates, latencies, throughput. Service topologies
- Reliability: Retries, timeouts, load balancing, circuit breaking
- Security: Transparent mTLS, cert management and rotation, policy

Most Service Mesh Plataforms are based on Envoy Proxy, but it isn't The Linkerd case. 

Use a "micro-proxy" Rust-based let the project to..
- avoid a entire class of memory vulnerabilities. 
- compiles to native code(no runtime env/GC). So it can be ultralight and ultrafast 
- built on Tokio, Hyper, H2, Tower and the rest of modern Rust async networking stack. 

Linkerd has huge numbers and benchmark results:
- 4+ years in production
- 5,000+ Slack channel members
- 10,000+ GitHub stars
- 100+ contributors
- Weekly edge releases
- Open governance, neutral home
- Tl;dr: really fast. Not as fast as "no service mesh", but significantly smaller and faster than Istio.

Don't use Linkerd if your app..
 - ..is a monolith
 - ..that communicate purely via Kafka or another distributed queue

###Previous Post
 - [Linkerd: Install and Basic Ops](https://dev.to/cedon/linkerd-install-and-basic-ops-2l90)

###References
 - Linkerd Docs - https://linkerd.io/docs
 - [Course: Introduction to Service Mesh with Linkerd](https://www.edx.org/course/introduction-to-service-mesh-with-linkerd)
 - CNCF - https://www.cncf.io/
 - gRPC - https://grpc.io/
 - Rust - https://www.rust-lang.org/
 - Golang - https://golang.org/
 - Kinvolk Benchmark - https://kinvolk.io/blog/2019/05/performance-benchmark-analysis-of-istio-and-linkerd/
 - Tokio - https://tokio.rs/
 - Hyper - https://github.com/hyperium/hyper
 - H2 - https://github.com/hyperium/h2
 - Tower - https://github.com/tower-rs/tower
 - Kafka - https://kafka.apache.org/intro