Hello, Habr! I present to your attention the translation of the article. Service Mesh Data Plane vs Control Plane author Matt Klein.

This time, I wanted to translate the descriptions of both components of the service mesh, data plane and control plane. I found this description to be the clearest and most interesting, leading to the question, "Is it even necessary?"

As the concept of Service Mesh has gained popularity over the last two years (original article from October 10, 2017), and the number of participants in the space has increased, I have noticed a corresponding rise in confusion within the technical community about how to compare and contrast different solutions.

The situation is best described by the following series of tweets I wrote in July:

Service Mesh Confusion #1: Linkerd ~ = Nginx ~ = HAProxy ~ = Envoy. None of these is equal to Istio. Istio is something completely different. 1 /

The first ones are just data planes. By themselves, they do nothing. They need to be configured for something greater. 2 /

Istio is an example of a control plane that ties the parts together. It is a different layer. /end

The previous tweets mention several different projects (Linkerd, NGINX, HAProxy, Envoy, and Istio), but more importantly, they introduce the common concepts of data plane, service mesh, and control plane. In this post, I will take a step back and explain what I mean by the terms 'data plane' and 'control plane' at a very high level and then explain how these terms relate to the projects mentioned in the 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 (A-D). Each service instance is connected to a local proxy server. All network traffic (HTTP, REST, gRPC, Redis, etc.) from an individual application instance is routed through its local proxy server to the corresponding external service clusters. Thus, the application instance is unaware of the overall network and only knows about its local proxy. Essentially, the network of a distributed system has been abstracted from the service.

Data Plane

In a service mesh, the proxy located locally to the application performs the following tasks:

• Service Discovery. What services/applications are available for your application?
• Health Checking. Are the instances of services returned by service discovery healthy and ready to accept network traffic? This may include both active (e.g., response check/healthcheck) and passive (e.g., using three consecutive 5xx errors as an indication of an unhealthy service state) health checks.
• Routing. After receiving a REST request to "/foo", which service cluster should the request be sent to?
• Load Balancing. Once a service cluster has been chosen during routing, which instance of the service should receive the request? With what timeout? With what circuit breaking settings? If the request fails, should it be retried?
• Authentication and Authorization. For incoming requests, can the calling service be cryptographically identified/authorized using mTLS or another mechanism? If it is identified/authorized, is it permitted to invoke the requested operation (endpoint) in the service or should an unauthorized response be returned?
• Observability. For every request, detailed metrics, logs, and distributed tracing data should be generated so that operators can understand the distributed flow of traffic and debugging issues as they arise.

The data plane in the service mesh is responsible for all the previous points. Essentially, the local service (sidecar) proxy is the data plane. In other words, the data plane is responsible for the conditional translation, forwarding, and monitoring of every network packet that is sent to or from the service.

The Control Plane

The network abstraction provided by the local proxy in the data plane is quite remarkable. However, how does the proxy actually learn about the route "/foo" to service B? How can the service discovery data filled by proxy requests be utilized? How are load balancing, timeout, circuit breaking, etc., configured? How is application deployment handled using blue/green methods or traffic shifting? Who sets the parameters for system-wide authentication and authorization?

All of the above is managed by the control plane of the service mesh. The control plane takes a set of isolated proxies without state and transforms them into a distributed system.servers I believe the reason many technologists find the concepts of data plane and control plane confusing is that the data plane is familiar to most people, while the control plane is foreign or unclear. We have long been working with physical network routers and switches. We understand that packets/requests need to go from point A to point B, and what hardware and software we can use for that. The new generation of software proxies are merely trendy versions of tools we've been using for a long time..

Figure 2: Human control plane

However, we have long been utilizing control planes, even though most network operators may not associate this part of the system with any technological component. The reason is simple:

Most control planes in use today are... we
in Figure 2.

At Figure 2 What I'm referring to as the 'Human control plane' is shown. In this type of deployment, which still occurs quite frequently, a human operator, likely grumpy, creates static configurations—potentially using scripts—and deploys them through some special process across all proxy servers. The proxies then begin to utilize this configuration and start processing the data plane using the updated settings.

Figure 3: Advanced service mesh control plane

At in figure 3 illustrates the 'advanced' control plane of the service mesh. It consists of the following parts:

• The human: There is still a human (hopefully less angry) making high-level decisions regarding the entire system.
• Control plane UI: The human interacts with some type of user interface to manage the system. This can be a web portal, a command-line interface (CLI), or some other interface. Through the user interface, the operator has access to global system configuration parameters such as:
  • Deployment management, blue/green and/or gradual traffic shifting
  • Authentication and authorization parameters
  • Routing table specifications, for example, what happens when application A requests information about '/foo'
  • Load balancer settings, such as timeouts, retries, circuit breaking parameters, etc.
• Workload scheduler: Services are launched in the infrastructure via a scheduling/orchestration system of a certain type, such as Kubernetes or Nomad. The scheduler is responsible for loading the service along with its local proxy.
• Service discovery. When the scheduler starts and stops service instances, it reports the health state to the service discovery system.
• Sidecar proxy configuration APIs : Local proxy servers dynamically extract state from various system components based on the 'eventually consistent' model without operator input. The entire system, consisting of all currently running instances of services and local proxy servers, ultimately converges into a single ecosystem. The universal data plane API in Envoy is one example of how this works in practice.

Essentially, the purpose of the control plane is to establish policies that will ultimately be accepted by the data plane. More advanced control planes will abstract away more details from the operator and require less manual intervention, assuming they function correctly!..

Data Plane vs. Control Plane Summary

• Service Mesh Data Plane: affects every packet/request in the system. It is responsible for application/service discovery, health checks, routing, load balancing, authentication/authorization, and observability.
• Service Mesh Control Plane: provides policies and configuration for all active data planes within the service mesh. It does not touch any packets/requests in the system. The control plane turns all data planes into a distributed system.

Current Project Landscape

Having clarified the explanation above, let’s take a look at the current state of the service mesh project.

• Data Planes: Linkerd, NGINX, HAProxy, Envoy, Traefik
• Control Planes: Istio, Nelson, SmartStack

Instead of diving into an in-depth analysis of each of the solutions mentioned above, I will briefly touch on some points that I believe are causing much of the confusion in the ecosystem right now.

In early 2016, Linkerd was among the first data plane proxies for service mesh and did a fantastic job of raising awareness and increasing attention to the service mesh design pattern. About six months later, Envoy joined Linkerd (although it had been working at Lyft since late 2015). Linkerd and Envoy are the two projects most commonly mentioned in discussions about service meshes.

Istio was announced in May 2017. The goals of the Istio project are very similar to the extended control plane shown in in figure 3. Envoy for Istio serves as the default proxy. Thus, Istio is the control plane while Envoy is the data plane. In a short time, Istio caused a lot of excitement, and other data planes began integrating as alternatives to Envoy (both Linkerd and NGINX demonstrated integration with Istio). The fact that different data planes can be used within a single control plane means that the control plane and the data plane do not necessarily have to be tightly coupled. An API like the universal data plane API can serve as a bridge between the two parts of the system.

Nelson and SmartStack further illustrate the separation of the control plane and the data plane. Nelson uses Envoy as its proxy and builds a resilient control plane for the service mesh based on the HashiCorp stack, i.e., Nomad, etc. SmartStack has become perhaps the first of the new wave of service meshes. SmartStack forms a control plane around HAProxy or NGINX, demonstrating the possibility of decoupling the control plane of a service mesh from its data plane.

Microservice architecture with a service mesh is gaining more attention (rightfully so!), and more projects and vendors are beginning 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 various components. Ultimately, microservice architecture should become more transparent and magical (?) for the operator.
I hope that everyone is becoming less and less irritated.

Key takeaways

• A service mesh consists of two distinct parts: the data plane and the control plane. Both components are essential, and without them the system will not function.
• Everyone is familiar with the control plane, and right now the control plane could be you!
• All data planes compete with each other in terms of functionality, performance, configurability, and scalability.
• All control planes compete with each other in terms of functionality, configurability, scalability, and ease of use.
• One control plane can contain the right abstractions and APIs to allow for the use of multiple data planes.

Source: habr.com