According to CNCF’s latest annual survey, many organizations have shown a high level of interest in Service Mesh, and some are already using them in production environments. You may not know that Linkerd was the first Service Mesh on the market, but Istio made Service Mesh more popular. Both projects are cutting edge and the competition is so fierce that it is difficult to choose one. In this article, we’ll learn about Istio and Linkerd architectures, components, and compare their products to help you make informed decisions.
Service introduction of Mesh
Over the past few years, microservices architecture has become a popular style in software design. In this architecture, we decompose the application into independently deployable services. These services are usually lightweight, multilingual, and are often developed and deployed by a variety of functional teams. The microservices architecture will remain effective as certain services grow in number, are difficult to manage, and become more complex. But it also poses challenges in managing security, network traffic control and observability.
Service Mesh is a great way to help address these challenges.
- The Service Mesh describes the microservices that make up the application and the interactions between them. As the number of services increases and complexity increases, scaling and management becomes more difficult. Service Mesh provides Service discovery, load balancing, fault recovery, metrics, and monitoring for microservice architectures.
- Service Mesh can also typically meet more complex requirements, such as A/B testing, Canary publishing, rate limiting, access control, and end-to-end authentication.
- Service Mesh provides an easy way to create Service networks with load balancing, service-to-service authentication, monitoring, and more with little or no microservice code changes.
Next, let’s compare Istio’s architecture with Linkerd’s. Note that both projects are rapidly evolving and this article is based on Istio version 1.6 and Linkerd version 2.7.
Istio
Istio is an open source platform that provides a complete solution as a Service Mesh, providing a unified way to secure, connect, and monitor microservices. It is backed by industry leaders such as IBM, Google and Lyft.
Istio is one of the most popular and complete solutions, with premium products for businesses of all sizes. Istio is a first-class citizen of Kubernetes and is designed as a platform independent modular system.
Architecture (Architecture)
Components (Components)
Envoy is a high-performance proxy written in Lyft’s C ++ language that can proxy all inbound and outbound traffic for all services in the Service Mesh. It is deployed as a Sidecar agent.
Envoy provides the following features:
- Dynamic service discovery
- Load balancing
- The TLS to terminate
- HTTP/2 and gRPC agents
- The circuit breaker
- Health check
- Distribute traffic by percentage
- Fault injection
- Rich indicators
In newer versions of Istio, Sidecar agents also perform a portion of Mixer work. In earlier versions of Istio (<1.6), Mixer was required to gather data information from the service grid.
Pilot provides service discovery for Sidecar agents, traffic management capabilities, and elastic scaling. It translates high-level routing rules that control traffic behavior into envoy configurations.
Citadel implements user authentication through built-in identity and credential management.
Galley configures authentication rules (Pilot and Citadel configuration rules) in Istio.
The core function
- Traffic Management – Management of intelligent traffic routing rules, traffic control, and service-level attributes such as circuit breakers, timeouts, and retries. It allows us to easily set up A/B tests, Canary releases, rolling upgrades, etc.
- Security – Provides secure communication channels between services and manages authentication, authorization, and encryption.
- Observability – Powerful tracing, monitoring, and logging capabilities provide visibility. It helps to detect and resolve problems quickly and efficiently. Istio can also be integrated with applications such as Prometheus, Grafana, Jaeger and Kiali.
Linkerd
Linkerd is an open source lightweight service grid. Rewritten entirely in Rust in version 2.0 to make it ultra-lightweight and high-performance, it provides runtime debugging, observability capabilities.
Architecture
Linkerd has three Components — UI, Data Plane and Control Plane. It works by installing lightweight transparent objects next to each service instance.
Control Plane
Provide core functionality. It aggregates data and provides a user-facing API. The following are the Components of the Control Plane.
- Controller – It consists of a common API container that provides CLI and dashboard apis.
- Destination – Each agent in the Data Plane will call this component to find where to send the request. It can configure routing metrics, retries, and timeout information.
- ** Identity — ** It provides a Certificate Authority that accepts CSRs requests from agents and returns identif-signed certificates. It also provides mTLS functionality.
- Proxy Injector – This is an access controller that looks for an initContainer with the annotation (Linkerd. IO/Inject: enabled) and changes the POD information to add a Proxy container.
- Service Profile Validator – This is also an admission controller that validates new Service profiles before saving them.
- Tap – It receives requests from the CLI or dashboard to monitor requests and responses in real time to provide visibility in the application.
- Web – Provides Web dashboards.
- Grafana — Linkerd provides dashboards out of the box through Grafana.
- Prometheus — it collects and stores all Linkerd metrics by grabbing proxy endpoint data on port 4191 via /metrics.
Data Plane:
The Linkerd Data Plane consists of lightweight agents deployed as sidecar containers. The proxy is injected during the Pod initialization phase (see proxy injector above). Since 2.x was completely rewritten in Rust, the agent is very lightweight and performs well. These agents intercept communication between each Pod to provide detection and encryption (TLS) without changing application code.
Proxy function:
- Transparent, zero-configuration proxy for HTTP, HTTP2, and any TCP protocol.
- Automatically exports Prometheus indicators for HTTP and TCP traffic.
- Transparent zero configuration WebSocket proxy.
- Automatic, delay-aware 7-layer load balancing.
- Automatic Layer 4 load balancing for non-HTTP traffic.
Compare the way
| Characteristics of the | Istio | Linkerd |
|---|---|---|
| Easy to install | The various configuration options and flexibility can overwhelm teams | Out of the box configuration, installation is relatively easy |
| platform | Kubernetes, virtual machine | Kubernetes |
| Supported protocols | GRPC, HTTP/2, HTTP/1.x, Websocket and all TCP traffic | GRPC, HTTP/2, HTTP/1.x, Websocket and all TCP traffic |
| Inlet controller | Envoy, Istio gateway itself | Linkerd itself does not provide entry functionality |
| Multiple clustering and scaling support | Multiple cluster deployments are supported through various configuration options and the grid can be extended outside the Kubernetes cluster | Starting with version 2.8, multi-cluster deployment has stabilized. |
| Service Mesh Interface (SMI) compatibility | Through a third-party CRD | This machine is used for traffic splitting and indicators, not for traffic access control |
| Monitoring function | feature-rich | feature-rich |
| Track support | Jaeger, Zipkin | Support for all back ends of OpenCensus |
| Routing functions | Various load balancing algorithms (round-robin, Random Least Connection) support traffic splitting based on percentage and traffic splitting based on headers and paths | Supports EWMA load balancing algorithm and supports traffic splitting based on percentage through SNI |
| The elastic | Circuit breakers, retry and timeout, fault injection, delay injection | No circuit breakers, no delay injection support |
| security | MTLS supports all protocols, can use external CA certificates/keys, and supports authorization rules. | In addition to TCP, mTLS is supported and external CA/keys can be used, but authorization rules are not yet supported |
| performance | In the latest 1.6 release, Istio has become increasingly resource-intensive and latency has improved. | Linkerd is designed to be lightweight and, according to some third-party benchmarks, three to five times faster than Istio. |
| Enterprise support | Not applicable to OSS version. If you use Google’s GKE with Istio, or Red Hat OpenShift with Istio as a Service Mesh, you may get support from various vendors. | Buoyant, which developed a version of Linkerd OSS, provides complete enterprise-level engineering, support, and training |
conclusion
Service Mesh is becoming an important part of cloud native solutions and microservice architectures. It enables you to do all the grunt work, such as traffic management, resilience, and visibility, and takes the focus off the business logic of the developer.
Both Istio and Linkerd are mature and have been used in production environments by many enterprises. Planning and analysis of software project requirements is critical to selecting the Service Mesh to use. Take as much time as you need to get the technology right in the beginning, because it can be complicated to make changes later.
reference
- Dzone.com/articles/wh…
- Martinfowler.com/articles/mi…
- Istio. IO/docs/concep…
- Service Mesh
- Freepik.com headlines and featured images