Illustrating Istio⛵

#devops #kubernetes #go #opensource

This article will cover the introduction, basics, and uses of a Istio.

Prerequisites ✅

I am assuming that you understand the basics of a Kubernetes cluster.

Being said that. Let's get started!

Introduction 💡

Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments.

Swuusshh over the head am I right? 😂

Istio is a Service Mesh. It enables services to detect each other and communicate within and outside the cluster. The tool has many other verticals which we will discuss in detail later.

Before understanding Istio, there are two major concepts to understand:

Sidecar
Service Mesh

Sidecar 🚘

Kubernetes Sidecar Containers are those containers that run parallel to the main container in the pod. Say each pod in your container has an assistant/butler for itself (Yes! if your deployments were Batman, the sidecar is its Alfred).
It is responsible to handle all the secondary tasks of your deployment(The pod that ran your container). It can take care of logging, security, routing, health checks, and more.
A good read on this: Here

Easiest way to understand a Sidecar in any setup

Service Mesh 🕸️

Need:

In the world of monolith, there was one system running a set of programs. In case of failure, it was easier to debug it since we knew where the logs will be found.
But in today's world of microservices, it's hard to do the same job. The architecture which is based on a distributed system it is hard to trace a request. It might have failed on some other machine that might not even be located in the same time zone as yours. It might be a different pod in the same node or a different container in the same pod.

Solution:

Build a system that handles the communication between your Pods. This system is responsible to handle all the communication among all the pods. It can track requests, keep logs and also handle security. We will talk in detail about Service Mesh in this article.
A good read: Here

Istio

Istio is one of the best Open Source service mesh out there! Most companies have adopted it and CNCF has been supporting it for a very long time now. Moving ahead, we understand the purpose of a Service mesh.
There are multiple purposes of the project I will mention the major ones:

Secure the communication of your microservices/pods with TLS encryption and other authentication methods.
Load balance the traffic that the services received.
It can work as Ingress. A pre-processor for each request before the request is actually made to your app.
It can handle Policy, metrics, and observability as well

Most handy feature according to me, is Visualising your architecture. Yes! it provides a GUI to understand and help you understand the setup. It is really handy to SREs in case of failures. I worked with it.
The steps to implement it on your Cluster: Here

Istio Architecture

Well like Kubernetes, the architecture of Istio has two basic classifications of its components. The master-worker architecture follows here as well. It has basically two planes: