Istio Architecture

• Service Mesh → Paradigm or Pattern

• Istio → Implementation of Service Mesh

Comparison:

Here, Envoy proxy is in itself an independent open-source project used by several other service mesh implementations.

Before v1.5 of Istio, the Control Plane had many components such as Pilot, Galley, Citadel, Mixer, etc.

After v1.5 → all these components got combined into one → Istiod → This made it easier for operators to manage and configure Istio

Control Plane also manages Data Plane which is a group of Envoy proxies.

How to configure Istio?

How do we configure all these above features for our microservices in Istio.

• You don't have to adjust deployment and service K8s YAML files for your microservices

• Istio configuration separate from application configuration

  So all the configuration for Istio components will be done in istio itself, again having a clear separation between, the application logic & configuration; and the service mesh logic & configuration.

• Istio can be configured with Kubernetes YAML files.

  • Istio used K8s CRD Custom Resource Definition.

    • extending the kubernetes API

    • custom kubernetes component/object for allow configuring third party techs like istio , prometheus etc. using the same kubernetes yaml files and apply them using kubectl without having to learn a technology specific configuration language and adjusting that configuration directly inside istio for example

So using a few Istio CRD, we can configure different traffic routing rules between our microservices like which services can talk to each other, traffic split configuration, the retry rules, timeouts and many other network configurations!

There are two main CRD for configuring service to service communication

• virtual service

  This configures How you route the traffic TO a specific service

• Destination rule

  Configure what happens to traffic FOR that service.

1. We Create CRDs

2. Istiod converts these high level routing rules into Envoy specific configurations

3. Configuration is propagated into Proxy sidecars

We Don't configure proxies, we configure control plane!

And control plane itself will then push that configuration out to all individual envoy proxies and the proxies themselves can now communicate with each other by applying this configuration that we define without having to go back to the Istio control plane. So they can independently talk to each other because they have all the logic and configuration they need without talking to the control plane.

Istio Features

• Service Discovery

• Security

• Metrics and Tracing

1. Service Discovery in the cluster

Istio offers several key features, including service discovery, security, metrics, and tracing. In addition to configuring the proxies, Istio provides a central registry for all microservices. This means that instead of manually configuring endpoints for each microservice, when a new microservice is deployed, it is automatically registered in the service registry without the need for additional configuration. Istio accomplishes this by automatically detecting services and endpoints in the cluster. The Envoy proxies can then query the endpoints to route traffic to the relevant services.

1. Certificate Management

Another crucial feature of Istio is its role as a certificate authority (CA). It generates certificates for all microservices in the cluster, enabling secure TLS communication between the proxies of these microservices.

1. Metrics and Tracings

Istio also collects metrics and tracing data from the Envoy proxies. This data can be later consumed by monitoring servers like Prometheus or tracing servers, providing out-of-the-box metrics and tracing for your entire microservice application.

Istio Gateway

Istio includes another component called as an ingress gateway, which serves as an entry point into your Kubernetes cluster. Think of it as an alternative to the Nginx ingress controller. The Istio ingress gateway runs as a pod in your cluster and acts as a load balancer, accepting incoming traffic and directing it to one of your microservices within the cluster using the virtual service component. You can configure the Istio gateway using a Gateway Custom Resource Definition (CRD).

Traffic Flow with Istio

In the traffic flow within your Kubernetes cluster, with all the Istio components in place, here's how it works:

1. A user initiates a request to a web server microservice in your Kubernetes cluster.

2. The request first reaches the gateway, which serves as the entry point to the cluster.

3. The gateway evaluates the virtual service rules that dictate how to route the traffic. It then forwards the request to the web server microservice.

4. The request eventually reaches the proxy, specifically the Envoy proxy within your web server microservice.

5. The Envoy proxy evaluates the request and forwards it to the actual web server container within the same pod using the localhost connection.

6. The web server, in turn, initiates another request, perhaps to a payment microservice.

7. This request flows from the web server container to the web server proxy.

8. The web server proxy, guided by virtual service rules, destination rules, and other configurations, communicates with the Envoy proxy of the payment microservice using mutual TLS (secure)

9. This pattern repeats for communication between the payment service and the database, and for the return journey of the response.

   

10. Throughout this entire request flow, the proxies collect metrics and tracing information about the requests and send it back to the Istio control plane.

11. This provides automatic monitoring for your application, giving you insights into its performance and behavior.

That's it!

Istio orchestrates the flow of traffic within your Kubernetes cluster, ensuring secure and controlled communication between microservices while also offering built-in monitoring capabilities for your application.