Shulou(Shulou.com)06/01 Report--

This article is to share with you about how to compare Linkerd and Istio frameworks in Service Mesh. The editor thinks it is very practical, so I share it with you. I hope you can get something after reading this article.

Introduction:

Organizations in various industries and areas are continuing to accelerate the adoption of micro-service architecture. This is followed by an explosive growth in the use of containers and communication between endpoints and services. The complexity and uncertainty within the enterprise are increasing. How to manage the security and visibility of large-scale communication under such circumstances is quite a challenge. Therefore, both operators and developers have a strong desire to encapsulate the complexity of the network layer into a new network infrastructure layer. At this point, the most popular way to deal with this is the Service Grid (Service Mesh).

Therefore, we will compare the characteristics of the two mainstream service networks to find out the similarities and differences between the two, namely Linkerd and Istio.

What is the service grid?

Service grid is a proprietary infrastructure layer, which can make the communication between services within the micro-service architecture more reliable, fast and secure. The basic idea is to insert a network of agents between services to realize the abstraction of the network layer. In a word, the service grid is designed to help developers solve the interaction challenges between micro-services.

What is Istio?

Istio is an open source service grid project initiated by Google, IBM and Lyft. The project was launched in 2017 and version 1.0 was released in July 2018. Istio is based on the Envoy agent and uses it as the data layer (data plane). It can be said that Istio is the hottest service grid today, but because it is only applied to Kubernetes, its application value is limited to some extent.

What is Linkerd?

Linkerd (sounds like chickadee) was originally a service grid project created by the Buoyant team in 2016. Linkerd is the official project of CNCF, and the Finagle project based on Twitter, like the latter, was originally written in the Scala language and was designed to support host-based deployment patterns (physical hosts or virtual nodes). Because the initial version of the memory footprint was widely criticized, led to the development of the Conduit project, Conduit is a lightweight service grid, customized for Kubernetes, written in Rust and GE languages. The Conduit project has now been merged into the Linkerd project and was released as Linkerd version 2.0 in July 2018. Given that Linkerd 2.x is based on Kubernetes, while Linkerd 1.x can be deployed in a node-based pattern, people can have more flexible choices when faced with scenarios in complex environments. Unless specifically mentioned, the comparisons in this article are based on Linkerd 2.x.

IV. Comparison of features and functions

Architecture

Both Istio and Linkerd support deployment in mainstream plug-in (Sidecar) mode. In this mode, each microservice is assigned a separate agent. The communication between microservices is not carried out directly, but is forwarded through its own agents. The agent routes the request to the agent of the target microservice, which in turn forwards the request to the target microservice. All of these service agents make up the data layer. Under the architecture of service grid, the data layer is configured and monitored by the control layer (control plane), and the control layer is generally deployed independently.

Architecture diagram: take Istio as an example. The Envoy agent is deployed in an external form. In such a deployment model, the agent is injected into each container unit, so it can be configured independently. The Istio control layer consists of many components that are used to configure, measure, control and secure communication between services.

Control layer

The mission of the control layer is to control the agents within the service grid through a series of API and tools. In the control layer, the entire data layer can be used as a whole to specify authentication policies, collect metrics, and configure them.

The control layer of Istio consists of three components. First is Pilot, which is responsible for configuring the data layer. The second is Mixer, which is responsible for collecting traffic metrics and responding to various query requests in the data layer, including authorization, access control and quota queries. Depending on the adapter enabled, Mixer can also be docked with the logging and monitoring system. Finally, there is Citadel, a component that allows developers to establish a network environment with zero trust (zero trust, zero-trust, in short, assuming that all communicators are untrusted and must be verified) based on service authentication rather than network control. Citadel is responsible for specifying certificates for each service and can accept external certificate authorization keys if necessary.

Bai Xiaobai:

The control layer of Linkerd consists of a Web component, a control component, and a measurement component. The Web component provides a Web-based management dashboard. The control component consists of multiple container deployments. Completed most of the functions of the control layer (including aggregating telemetry data, providing user interface API, providing control data for the data layer, etc.). The measurement component consists of customized Prometheus and Grafana. Prometheus is responsible for grabbing Linkerd exposure metrics and storing them. Linkerd itself generates a lot of external panels, and Grafana is responsible for rendering and rendering these panels.

Data layer

In a typical service grid environment, the deployment process of the service will be incorporated into a proprietary plug-in agent. As mentioned earlier, the service does not deliver messages directly to the network, but is communicated by its own agent. Such a mechanism encapsulates the complexity of communication between services. The agents in the service grid are connected to each other to form the data layer.

By default, Istio uses Envoy as the data layer, and Envoy was originally designed to work with other types of agents, such as Nginx. Linkerd uses its own proxy.

Platform support

Although he claims to support a large number of environments and frameworks, in practice, Istio can only get along well with kubernetes, which seriously limits his scope of application.

Linkerd 2.x also needs to work with Kubernetes currently. However, Linkerd 1.x is widely deployed and active in research and development, and can work in a variety of environments and frameworks, including working with AWS ECS, DC/OS, and Docker. The ability to support such a wide range of environments benefits from the host-based deployment model of Linkerd 1.x, which allows it to be integrated with the user's environment without the need for external deployment.

Linkerd 1.x host deployment model: the linkerd service grid can be deployed based on hosts. Based on this pattern, multiple microservices on the same host share a Linkerd (1.x) instance.

The main disadvantage of the host deployment model is that the failure of a single point of agent will affect multiple microservices. On the other hand, the host deployment mode consumes less resources than the plug-in mode.

Protocol support

Based on plug-in agents, Istio and Linkerd 2.x both support inter-service communication with HTTP 1.1, HTTP2, gRPC and TCP protocols. However, Linkerd 1.x does not support TCP connections.

Implementation language

The control layer of Istio and Linkerd 2.x are written in the GE language, the Envoy agent of the Istio data layer is written by C++, and the data layer of Linkerd 2.x is written in Rust. Linkerd 1.x is written in Scala.

Security, encryption and authorization

The control layer component of Istio provides the following security functions: Citadel: key and certificate management. Pilot: distribution of authentication policies and security naming information. Mixer: management of authorization and audit. Plug-in: to achieve secure communication between agents based on TLS encryption.

At the time of this writing, the automatic TLS encryption of Linkerd is still in the experimental stage, and the authentication between hosts has not been supported.

Plug injection

The process of adding a plug-in to the deployment package and registering at the control layer of the service grid is called plug-in injection. Both Istio and Linkerd support manual and automatic plug-in injection.

High availability

Istio supports high availability if and only if multiple copy mode of Kubernetes is configured and the podAntiAffinity switch is turned on.

The high availability of linkerd is still in the experimental stage.

Monitoring and tracking

Istio natively supports Prometheus and integrates Jaeger for distributed tracking. Linkerd supports Prometheus and Grafana monitoring from the outside, but currently does not support distributed tracing.

Performance

The general performance overhead of Linkerd 2.x is generally lower than that of Istio. A performance test on both shows that, based on a set of test loads composed of HTTP requests, the benchmark number of queries per second (kqps) is 30-35kqps. After forwarding through the agent, the performance is degraded, Linkderd to 10-12kqps and Istio to 3.2-3.9kqps.

When should the service grid be used cautiously?

There are five main reasons that may prevent you from considering using a service grid to manage the potential network complexity challenges posed by a micro-service architecture.

1. Service grid is exclusive.

Service grid is a platform solution and is therefore exclusive. This means that you will be forced to choose between "obeying them" and "choosing the right way based on my own business and technical considerations". Depending on your situation, the upfront investment in the service grid can be very expensive.

Moreover, if controlling communication between applications and services is strategically important to your organization, there is no point in using an off-the-shelf service grid. This may benefit from the benefits of the growth of the framework, but you can't control your goals.

2. Service grid is complex.

The deployment of the service grid will introduce considerable complexity into your architecture. The deployment process requires the introduction of plug-in agents, the service grid needs to be integrated with the existing environment and configured repeatedly in the future, and all encryption may need to be redesigned. Building an instance of a service grid based on a platform like Kubernetes will require you to be not only an expert on the service grid, but also an expert familiar with Kubernetes.

3. The service grid may run slowly.

With the expansion of the grid and the expansion of the routing table, routing communication through a series of agents will be slow and painful.

4. Service grid tends to establish an autonomous architecture blueprint.

Using a service grid to track communication requests between services does not always look as valuable as it did at first. For example, if your microservice environment is integrated with the applications and services of other teams, it will be challenging to translate different tracking records across the boundaries of different technical teams and business units. in the case of an enterprise environment or a cloud provider, this challenge will be even more severe.

5. The service grid focuses on the considerations at the developer level

Service grid focuses on the problem of inter-service communication from the perspective of typical developers. For large-scale and uncertain applications and services, the interaction between components will naturally lead to a series of complexity, and the service grid is powerless to control these emerging behaviors.

The above is how to compare the Linkerd and Istio frameworks in Service Mesh. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.