The purpose of the control plane is to set the policies and configurations for all of the data planes running as a service mesh. As we mentioned in Chapter 3, Service Mesh Architecture, an ideal service mesh should follow the ORASTAR principle. Take a look at the following diagram:

From the preceding diagram, we can see that the control plane satisfying the ORASTAR principle resides in the Kubernetes master nodes. You can run the control plane through the use of taints and tolerations to limit the control plane nodes to a set of dedicated nodes. The microservice with sidecar proxy applications running in worker nodes form a data plane. The control plane is a set of pods that communicate with the data plane's set of pods, which have a sidecar proxy.

Sometimes, the service mesh is also attributed to a mesh of a sidecar proxy, such as Envoy or Linkerd, which runs side by side with each microservice. Conceptually, this is true since a mesh is formed in the data plane. The control plane provides many more management capabilities apart from the sidecar proxy.

The Istio control plane has four main components:

• Pilot
• Mixer
• Galley
• Citadel

The control plane in Istio is like a hub and spoke architecture that manages the data plane that was created by the sidecar proxies of the application components or services:

Istio extends the Kubernetes API server for configuration management and access control. It uses Kubernetes' built-in datastore, called etcd, to store its state and configuration.

Now, let's take a closer look at these components, one by one.