ISTIO Architecture and Its Components

AS shown in above figure let us consider we have an application that has UI, Module Business logic, Payment and Inventory Microservice.
Now as they are microservice we want them to follow all the rules i.e.

Secure:- Microservice should talk to each other using secure platform.
Connect:- How the request flow should go i.e. how we can divert the 80% request to Module Businesslogic V1 and 20 % to Module Businesslogic V2 M/S.
Observer:- Need to check how the application is doing end to end.
control:- How to control the request i.e. UI can only do get to Module Businesslogic and do post to Payment etc
Scalable:- How the M/S instance need to be scale up and scale down depending on traffic.
Retry Policy:- Number of times the calling M/c need to be called in case of failure.
Cirtuit Breaker:- If one microservice is taking more time then it should respond it to calling M/S stating it fails to fetch the response.
Telemetry or Login:- How the login is taken care for future reference.
API Gateway :- i.e. Implementation of Ingress to perform API gateway approach.
Discovery Server :- i.e. Like Eureka to maintain the list of the M/S that is live and running.

All the above things that is specified is related to Network and nothing to do with M/S logic. So using developer time in this is not good.
Here comes the user of ISTIO as a service mesh.

ISTIO take all the above things in his hand and allow the developer to just write the code.
For doing this it uses the concept of side-car proxy design pattern. i.e. in this it will first inject a microservice that act as an proxy for all the microservice and is tightly coupled with it. IT has one to one relation withe M/C . I.e. as we have 4 M/C we will have 4 proxy Service as shown below.

Architecture of ISTIO and its component.

As shown above first we install ISTIO core component. This core component will inject Proxy side care M/S in to our system with 1 to 1 mapping.Now when ever the M/S want to take each other they have to go through Proxy. No direct communication is set between M/S. i.e. if Ui want to talk to payment it will send request to Proxy of UI M/S and then the request is send to Proxy of Payment and finally it reach to Payment M/S.

Additionally, ISTIO make sure that single Proxy and single M/S are placed in a single container i.e docker container so that they can communicate with each other using http://localhost. This will be taken care by Kubernetes framework.

Now the question is how we can inform Kubernetes to configure ISTIO. In practical ISTIO extends Kubernetes and hence to configure it we can write CRD.
We first write CRD i.e. *.yml files and gave it to Galley which will validate it and gave it to pilot which will convert that request into understandable language which proxy understand.

Further to add policy like 80% or 20% and certain rules like only get or post request is allowed can be done using policy component.
To check all the logs and what is happening inside the ecosystem using ISTIO we have telmentry component. All the proxy report them self to telementry component.

Finally, to generate, allocate and rollout https certificate to all the M/C we have citadel so that the proxy can do the mutual TLS when they talk to each others.

this ISTIO microservice was existing till 1.5 version now in above that version we are having only three components. components like telemntry and Policy are moved to proxy M/S .

now as we know the Architecture and behaviour of the ISTIO to configure it we need three main CRD.

Now these three CRD which is used to configured ISTIO are
1- Gateway CRD:- That will be responsible to take the request http/https from the outside world and send it to ISTIO. i.e. Zuul Server.
2- Virtual service CRD:- this can be either attached to the Gateway and divert the traffic to other M/S or it can be implemented between the M/S and we can implement policy like 80% and 20% canary deployment rules.
3- Destination policy CRD:- Once the request is sent to your M/S we can apply rule policy over top of that i.e. TLS and retry and circuit breaking etc.