Istio Service Mesh in Kubernetes and Auto Injecting It in the Kubernetes Pod as Side Car Container | Part-I
Today we will see, how to deploy Istio Service Mesh in local Kubernetes cluster and auto injecting it in the new deployments of Pods as a side car container.
Before we start with the hands on, let’s understand first,
According to official documentation, Modern applications are typically architected as distributed collections of microservices, with each collection of microservices performing some discrete business function. A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security, without adding them to your own code. The term “service mesh” describes both the type of software you use to implement this pattern, and the security or network domain that is created when you use that software.
As the deployment of distributed services, such as in a Kubernetes-based system, grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often addresses more complex operational requirements, like A/B testing, canary deployments, rate limiting, access control, encryption, and end-to-end authentication.
Service-to-service communication is what makes a distributed application possible. Routing this communication, both within and across application clusters, becomes increasingly complex as the number of services grow. Istio helps reduce this complexity while easing the strain on development teams.
According to official documentation, Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring — with few or no service code changes. Its powerful control plane brings vital features, including:
- Secure service-to-service communication in a cluster with TLS encryption, strong identity-based authentication and authorization
- Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic
- Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection
- A pluggable policy layer and configuration API supporting access controls, rate limits and quotas
- Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress
Istio is designed for extensibility and can handle a diverse range of deployment needs. Istio’s control plane runs on Kubernetes, and you can add applications deployed in that cluster to your mesh, extend the mesh to other clusters, or even connect VMs or other endpoints running outside of Kubernetes.
Why Service Mesh is required?
In current microservices world, everything is distributed where each of the microservice is doing some specific functions and these microservices also need to talk to each other to provide seamless experiences to the user. If we start maintaining network and observability and security related thing in our code, it will become impossible to maintain and also very difficult and tiresome to change and if the number of the services increases it will be more painful. To make this easy Service Mesh comes into picture, Service Mesh can help to manage our network related traffic in a efficient manner to support recent days, blue/green, canary etc. deployment models. It will also manage security related aspects of our services , TLS and it will keep a verbose logging, so that we can easily find out what has gone wrong.
To explain it in a better manner, Let’s say we have a service named SERVICEA and another service named SERVICEB. SERVICEA communicates with SERVICEB to get some data and perform some action. If we manage security related aspects in the code for this Service to Service communication, it will be very hard maintain, instead of that Istio can take care of that apart from that it will also handle retry, timeout etc. without making any code changes.
*Please note that above is a example in Microservices environment, we can also host the web application behind the Service Mesh as well.
Key Capabilities of a Service Mesh
- Traffic Management ( Discovery & Routing, Load Balancing, Failure Handling etc.)
- Security ( Encryption, Authentication, Authorization etc.)
- Observability ( Visualization, Tracing, Monitoring etc.)
How Istio works and where it sits?
Above example is classic example of Ambassador proxy services, deployed as a Side Car to accompany the lifecycle of a consuming application or service.
More on Ambassador Pattern,
What is a Side Car pattern and how it is useful?
A side car pattern is basically your application in a set of container with supporting function to provide isolation and encapsulation.
It is named as sidecar as you can think of it as a sidecar attached to a motorcycle. It shares the same lifecycle of the main application container.
For example, In a Pod there are two containers, one container is containing main application code and another container is containing the log support, this log support container will collect the logs from main container and send it to the main log aggregation tools such as Splunk etc.
Now we are done for today, in the Part-II we will learn how to deploy Istio in local Kubernetes cluster and how to leverage it to create side car containers.
For Reference,
Part of this Series,
