A service mesh provides a consistent, decentralized mechanism for managing communication between mul
A service mesh consists of two elements: the data plane and the control plane. As the names suggest, the data plane handles the actual forwarding of traffic, whereas the control plane provides the configuration and coordination. Let’s look at that in more detail.
In the service mesh architecture, the data plane refers to network proxies that are deployed alongside each instance of a service that needs to communicate with the other services in the system. All calls to and from a service go through the proxy, which can also apply authentication and authorization, encryption, rate limiting and load balancing, handle service discovery, and implement logging and tracing.
A service mesh decouples the application logic from the network communication logic, with the effect that application programmers do not need to worry about the practicalities of communicating with the wider network. Instead, the service only needs to know about its local proxy. In a microservice system where separate teams are developing services in different languages, a service mesh allows network communication and associated features to be implemented consistently without duplicating effort.
As we’ve seen above, the service mesh architecture requires a proxy for each instance of a service. In microservice-based systems comprising dozens or even hundreds of services, each of which may be replicated multiple times according to performance and reliability requirements, that results in an equal number of proxies to manage. This is where the control plane comes in.
The control plane exposes an interface for a human user to configure the behavior of the data plane proxies using policies and makes that configuration available to the proxies via another API (you may hear the user interface referred to as the management plane, but it is simply a view onto the configuration). Each data plane proxy must connect to the control plane in order to register itself and receive configuration details.
Because every call to a service goes via a proxy, the service mesh architecture adds an extra hop to every call. In order to minimize the additional latency, the proxy needs to be run on the same machine (virtual or physical) or in the same pod (in the case of containers) as the service for which it is proxying so they can communicate over localhost. This model is known as a sidecar deployment, hence the name “sidecar proxy.”
Although the service mesh architecture is not limited to microservice-based systems, they provide a good example of how a service mesh is used in practice. Let’s take the example of an online retailer that has adopted a microservice architecture covering functions such as stock control, shopping cart management, payments and user accounts. More services are in development, and the company has moved to cloud-hosted infrastructure to allow them to grow faster.
Using a service mesh to manage communications between these services means the platform team can apply mutual TLS encryption to all traffic within the system. Encryption had previously been implemented for communication between some of the services but was missing from the stock control service. Adding it to that service would have required the development team to re-implement the logic in C++, but due to other priorities, that work had not yet been done. By deploying a sidecar proxy to each service instance and provisioning them from the same certificate authority, the platform team is able to get all inter-service traffic encrypted using mutual TLS. The other development teams no longer have to maintain that part of their codebases.
Now that the online retailer has moved to cloud infrastructure, they want to be able to scale particular services when demand increases. The service mesh provides the service discovery function: as new instances are brought online, the proxy registers the instance with the control plane, which updates the configuration and makes it available to other proxies. The platform team uses the service mesh control plane to implement circuit breakers to prevent traffic from being routed to faulty instances.
The development teams also need more insight into the behavior of the system to assist in debugging issues quickly. By enabling trace logging to a separate log store, they can access details of every single call made within the system and use the data to unpick problems faster.
Implementing a service mesh to manage communication within a system can speed up deployment of microservices by providing a consistent approach that handles key networking features. The service mesh architecture is ideal for systems with a large number of services as it decouples networking concerns from application code and allows policies to be applied from a central source of truth, either universally or selectively based on specified criteria. To find out more about setting up your own service mesh, have a look at Implementing a Service Mesh.
Kubernetes architecture refers to the components required to deploy Kubernetes and the infrastructure on which they run. There are two main parts to the architecture: the worker nodes, which are the computers that run the containerized applications, and the control plane, which is responsible for deploying containers to worker nodes and managing failures.
The control plane includes the API server, scheduler, a key-value data store and controllers. These components allow you to configure your cluster and ensure that configuration is applied to the nodes. Worker nodes contain pods that hold your containers. They also include an agent to implement instructions from the control plane, a network proxy to enable communication with pods and the container runtime.
A cluster is a group of either physical or virtual machines that are connected over a network so that workloads can be shared between them.
A node is an individual machine in a cluster. Worker nodes host the pods that hold containers. A single node can host multiple pods (and therefore containers), depending on the available memory and CPU resource.