Service mesh, “Data plane” and “Control plane” (Service mesh data plane vs. control plane)

Hello, Habr! I present to you the translation of the article "Service mesh data plane vs control plane" by Matt Klein .

This time I wanted and translated the description of both components of the service mesh, data plane and control plane. This description seemed to me the most understandable and interesting, and most importantly leading to the understanding "Is it even necessary?"

As the idea of ​​a “Service mesh” has become more and more popular over the past two years (Original article October 10, 2017) and the number of participants in space has increased, I have seen a commensurate increase in confusion among the entire technical community regarding how to compare and contrast different solutions.

The situation is best described by the following series of tweets that I wrote in July:
Confusion with the service network (service mesh) No. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = Envoy. None of them are equal to Istio. Istio is something completely different. one /
The first are just data planes. They themselves do nothing. They need to be tuned for something more. 2 /
Istio is an example of a control plane that links parts together. This is a different layer. /end
Previous tweets mentioned several different projects (Linkerd, NGINX, HAProxy, Envoy and Istio), but, more importantly, introduced the general concepts of a data plane, a service mesh and a control plane. In this post I will take a step back and tell what I mean by the terms “data plane” and “control plane” at a very high level, and then I will tell how the terms relate to the projects mentioned in tweets.

What is a service mesh (really)?

Figure 1: Service mesh overview

Figure 1 illustrates the concept of a service mesh at the most basic level. There are four service clusters (AD). Each service instance is associated with a local proxy server. All network traffic (HTTP, REST, gRPC, Redis, etc.) from a single application instance is transmitted through a local proxy server to the corresponding external service clusters. Thus, the application instance does not know about the network as a whole and only knows about its local proxy. In fact, the network of the distributed system was remote from the service.

Data plane

In the service mesh (service mesh), a proxy server located locally for the application performs the following tasks:

For all the previous items in the service network (service mesh), the data plane is responsible. In fact, the proxy local to the service (sidecar) is a data plane. In other words, the data plane is responsible for conditional translation, forwarding and monitoring of each network packet that is sent to or sent from the service.

The control plane

The network abstraction that the local proxy in the data plane provides is magical (?). However, how does the proxy actually know about the "/ foo" route to service B? How can service discovery data that is populated with proxy requests be used? How are load balancing, timeout, circuit breaking, etc. configured? How to deploy the application using the blue / green (blue / green) method or the method of gradual transfer of traffic? Who configures system-wide authentication and authorization?

All of the above items are managed by the control plane of the service mesh. The control plane accepts a set of stateless isolated proxy servers and turns them into a distributed system .

I think the reason many technologists find the separated concepts of the data plane and control plane confused is because for most people the data plane is familiar, while the control plane is foreign / incomprehensible. We have been working with physical network routers and switches for a long time. We understand that packages / requests must go from point A to point B, and that we can use hardware and software for this. The new generation of software proxies is simply the trendy versions of the tools that we have used for a long time.

Figure 2: Human control plane

However, we have long used a control plane, although most network operators may not associate this part of the system with any technological component. The reason is simple:
Most of the control planes used today are ... us .

Figure 2 shows what I call the "Human control plane." In this type of deployment, which is still very common, the human operator, probably grumpy, creates static configurations - potentially using scripts - and deploys them using some kind of special process on all proxies. Then the proxies begin to use this configuration and begin processing the data plane using the updated settings.

Figure 3: Advanced service mesh control plane

Figure 3 shows the “extended” control plane of the service mesh. It consists of the following parts:

In essence, the goal of the control plane is to establish a policy that will ultimately be adopted by the data plane. More advanced control planes will remove more parts of some systems from the operator and require less manual control, provided that they work correctly! ..

Data plane and control plane. Data plane vs. control plane summary

Current project landscape

Having figured out the explanation above, let's look at the current status of the “service mesh” project.

Instead of conducting an in-depth analysis of each of the above solutions, I will briefly dwell on some points that, in my opinion, cause most of the confusion in the ecosystem right now.

In early 2016, Linkerd was one of the first proxy servers for the data plane for the service mesh and did a fantastic job of raising awareness and increasing attention to the service mesh design model. About 6 months after this, Envoy joined Linkerd (although he has been with Lyft since the end of 2015). Linkerd and Envoy are two of the projects that are most often mentioned when discussing service networks.

Istio was announced in May 2017. The goals of the Istio project are very similar to the extended control plane shown in Figure 3 . Envoy for Istio is the default proxy server. Thus, Istio is the control plane, and Envoy is the data plane. In a short time, Istio caused a lot of unrest, and other data planes started integrating as a replacement for Envoy (both Linkerd and NGINX demonstrated integration with Istio). The fact that you can use different data planes in the same control plane means that the control plane and the data plane are not necessarily closely related. An API such as the Envoy universal data plane API can form a bridge between two parts of the system.

Nelson and SmartStack help further illustrate the separation of the control plane and the data plane. Nelson uses Envoy as its proxy and builds a reliable control plane of the service mesh based on the HashiCorp stack, i.e. Nomad etc. SmartStack is perhaps the first of a new wave of service networks. SmartStack forms a control plane around a HAProxy or NGINX, demonstrating the ability to decouple a control plane from a service mesh and a data plane.

A microservice architecture with a service mesh is attracting more attention (right!), And more and more projects and vendors are starting to work in this direction. Over the next few years, we will see many innovations in both the data plane and the control plane, as well as further mixing of the various components. Ultimately, the microservice architecture should become more transparent and magical (?) For the operator.
Hope less and less annoyed.

Key points (Key takeaways)


All Articles