Hello, readers! This article talks about the Introduction to Istio as a Service Mesh product with some interesting information around it.
So, let us begin! 🙂
Understanding Service Mesh
In the era of a distributed system, the applications are being built in the form of microservices. These microservices sum up the entire architecture and also serve a business function. Every microservice performs a particular function to contribute to the overall functioning of the application.
With this hugely growing infrastructure in the form of microservices, it is essential for us to have control over the transparency of the architecture in terms of observability, traffic management, certificate management, security, etc.
This is when we can introduce Service Mesh as the layer of infrastructure for monitoring.
Service mesh is actually a layer of architecture that can be easily placed over the application. With Service Mesh, we can deploy the pattern of observability as well as have a layer of security and network control over the infrastructure.
It provides us service-to-service communication which is perhaps the reason for the existence of a distributed system all over.
In the upcoming section, we will be focusing on one such open-source Service Mesh product available to use.
Istio to the rescue!
As discussed, Istio is an open-source service mesh product. It is an additional layer of traffic management over the traditional distributed setup.
With Istio, we can enable an extra layer of security and monitoring over the existing infrastructure. It enables monitoring of the application in terms of traffic and service level engagement with minimal scope of code-level changes. The entire traffic can be monitored and controlled through Istio by its varied in-house resources.
We can have a large and wide ecosystem monitored and managed by Istio. Also, it serves as a load balancing setup for varied protocols under the service transactions.
Istio’s entire control management plane runs on Kubernetes, thus that gives us the benefit to add applications into the mesh as an existing setup.
Thus, it is indeed possible to integrate applications from varied backgrounds with Istio to have a mutually monitored ecosystem.
Features offered by Istio
- Istio provides secured service to service communication through TLS encryption.
- It offers easy load balancing services for TCP, HTTP traffic, etc.
- With Istio, we can enable logs and traces for traffic from within a Kubernetes cluster for all the inbound as well as outbound traffic.
- It offers fault injection and failovers for traffic management.
- The overhead of heavy deployments and Updation goes away with canary deployments and A/B testing.
Working of Istio as a Service Mesh
Having understood the features offered by Istio, let us now focus on the working of the underlying mesh infrastructure offered by Istio-
Have a look at the below diagram:
Istio has its underlying infrastructure into two components:
- Control plane
- Data plane
As we all know, Istio is a service mesh that manages the inbound as well as outbound traffic through a service base between containers and virtual machines.
Let us try to understand the contribution of these components for the traffic and network management-
1. Data Plane
The Data plane manages and monitors the network traffic at the network interception layer. It monitors all the traffic through the service base and enables us to implement a network full of managed services with authentication across the traffic.
- Data plane enables us to deploy services backed up by load balancing.
- End to end service level authentication is enabled by Data plane for the applications.
- Monitors and performs health checks for the network traffic.
2. Control Plane
The Control plane is responsible for securing the communication and exchange between the services. That is, it secures the service level communication through policies and configurations instead of engagement with packets or data paths.
The Control plane does this through some components that function towards this engagement:
- Envoy: It is responsible to apply policies and configurations between the traffic communication and it also intercepts the traffic flow accordingly.
- Citadel: This component is responsible for service to service authentication through mTLS. It offers and configures certificates and keys for a secure communication amongst the services.
- Pilot: It is responsible for handling the configurations and logic of envoy side cars. Piot manages the envoy proxies and does the load balancing across the base.
- Mixer: It takes the decision whether as to allow a certain traffic call from an envoy proxy component.
By this, we have approached the end of this topic. Feel free to comment below, in case you come across any questions.
For more such posts related Service Mesh, Stay tuned with us.
Till then, Happy Learning!! 🙂