Managing Communication Between Microservices Using Istio

When you deploy multiple containers each in a specific pod inside a Kubenetes Cluster, you’ll face new challenges compared to the monolith application concept. Each micro-service has its own business logic (BL), communication configs (COMM), retry logic (R), metrics – tracing logic (MT) as well as security logic (SEC). Therefore, managing those logics individually for each micro-service might be tedious and a time-consuming task, costly and even hard to control.

Photo Credits: TechWorld with Nana

Google defines Istio as “an open source service mesh that helps organizations run distributed, microservices-based apps anywhere”.

How Service Mesh Works

Using a sidecar Pattern, non-business logics are extracted and isolated in a sidecar proxy that handles all those logics acting as a proxy which through a control plane automatically injects the proxy in each microservice pod. The network layer composed of the proxies and the control plane is called a service mesh.

Photo Credits: TechWorld with Nana

Traffic splitting: a major core feature

Traffic split feature allows distributing traffic between multiple production versions of the same micro-service. This is useful when a 2.0 Beta version and a stable 1.0 version of a given micro-service are available, but there might be a bug in the 2.0 that couldn’t be caught with tests so the DevOps team wants to make sure that if something goes wrong with 2.0, users will be automatically redirected to 1.0 to avoid service interruptions.

Photo Credits: TechWorld with Nana

Istio, an implementation of Service Mesh

Istio uses envoy proxies (data plane), controlled by a control pane called Istiod that injects and manages the envoy proxies in each micro-service.

Istio configuration

Istio can be configured inside Kubernetes YAML filse since it uses CRD or Custom Resource Definitions that extends Kubernetes API to configure third-party applications like Prometheus, Istio etc.

Istio will convert those CRDs into Envoy-specific configurations, and the configuration will be propagated into proxy sidecars with auto-discovery and auto-registration, TLS communication as well as metrics data for every new micro-service.

Istio Ingress Gateway

Another component of Istio is Istio Ingress Gateway, you can think of it as an entry point to the Kubernetes cluster.

Photo Credits: TechWorld with Nana
Open chat
Powered by