Overview
Service Mesh and cloud native are becoming attractive topices during the recent years, and experiencing an upward trend. In order to advocate changes, developers may wonder if they can embrace service mesh of not . If service mesh is able to address your facing problem, the next step is to choose a suitable one.
When it comes to technology adoption among some popular service mesh implementations, one typical issue need to be noticed is about the data panel, as it raises the major overhead comparied with services that has not deployed in a service mesh style. Since inbound and outbound requests will go though such proxy for each service.
Linkerd2-proxy is an opensource service proxy designed to address service mesh communcation issues. While it is written in Rust, its peers and competitors, Envoy is written C++, which has been adopt by istio. Another proxy Mosn, introduced by SOFAMesh(deprecated now though), is an althernative for envoy as sidecar in istio environment and getting closer with industrial usage.
The following table do comparison between istio and linkerd and SOFAMesh
| Service Mesh | Istio | Linkerd | SOFAMesh |
|---|---|---|---|
| Proxy | Envoy | Linkerd2-proxy | Mosn |
| Proxy Language | Rust | C++ | Golang |
| Proxy Performance | Accepatble | Smaller and Faster | To be compared |
| Proxy Usage | General-purpose | Designed for service mesh sidecar | Designed for service mesh sidecar |
| Control Panel | Mixer+Pilot+Citadel/Istiod | public-api+tap+destination+controller+identity… | Mixer+Pilot+Citadel/Istiod |
Note that the perfomance comparison is based on this post, which is benchmarking Linkerd 2.3-edge-19.5.2 and Istio 1.1.6.
This post will focus on Linkerd2-proxy source code implementation, as well as its horizontal comparison with two other pupular data panels, Envoy and Mosn, aimining to figure out questions about:
- Performance comparison among these three.
- Scalabilty, core concept and funcionality for these three.
- Community support, popularity and trend comparison.
There are source code links and analysis for core concepts. Hope that it provides insights for your technology adoption decision.
And aslo note that for this post :
- Only focus on kubernetes-based service mesh.
- Source code analysis based on mater branch.
- May not analyze souce code in line-by-line style, but may help you capture the whole picture.
Table of Contents
- Overview
- Table of Contents
- Performance Comparison
- Scalability Comparison
- Community Attraction
- Reference
Performance Comparison
Sidecar proxy’s performance issues are conttibuted by serveral aspects, listed by following sub topics.
Traffic Hijacking
Hijacking traffic of the deployed service is the prerequests for sidecar proxy to come into effect. By using a set of tools, it enables sidecar proxy to be the only way that inbound and outbound traffic go through. Table below shows tools and methods used to implement traffic hijacking fort istio and linkerd respectively.
| Service Mesh | Istio | Sofa Mesh | Linkerd |
|---|---|---|---|
| InitContainer Needed | Yes | No | |
| Solution | k8s admission webhook injects istio-init which is based on proxy_init image, and using init shell script | Service Registry | |
| Hijack Method | Iptable-based | Traffic Takeover | |
| Default Redirected Port | 15001 | ||
| Sidecar proxy | Envoy | Mosn | Linker2-proxy |
| Optimization |
// todo
Mutil-threading model
How proxy processes traffic is an critical issue, as the proxy itself is somehow a middleware that acts like a secondary service, which processes all traffic from the business service transparently. Although sidecar proxy shares the same network namespace with the business service, communication overhead like tcp establishment cost can not be avoided. Such communication overhead has been illustrated by the blow figure from AWS App Mesh.
This subtopic will only focus on sidecar proxy internal machanism(the red arc part in above chart). It raises an really interesting point that Envoy, Linkerd2-proxy and Mosn are implemented in three distinguished language C++, Rust and Golang correspondingly. In this case, different languages bring different features and it plays an important role for the implementation of mutil-threading model.
Discovery Service
// pilot endpoin push perfromance issue, incremental xds, linkerd soluction
Scalability Comparison
| Sidecar | Envoy | Linkerd2-proxy | Mosn |
|---|---|---|---|
| Supported Platform | [Kuberbetes, Mesos and more](Kubernetes, Mesos, and more) | ||
| Multi-platform Support Component | Platform Adapter | ||
| xDS Support | ✅ | ✅ | |
| Protocol Extension Support | ✅ |
Community Attraction
Number of iteraction of software version, and how many issues and pull request related, are two critical figures to indicate popularity of open-source projects. The reason is that more popularity means more adoption, which leads to more issues raised and more pull request posted, and finally more iteraciton for the program. Funtionalities and features.
The time this post written is 2020/03/20, and istio is with version of 1.5and linkerd with version of stable-2.7.0