Kubernetes Istio simply visually explained
By: Kim Wuestkamp
Tags: Kubernetes, Istio, Continuous Delivery, Continuous Integration, DevOps

In image 5 all the istio-proxy containers have been programmed by the Istio Control Plane and contain all necessary routing information like seen in image 3/4. The nginx container from pod1-nginx makes a request to service service-python .

The request gets intercepted by the istio-proxy container of pod1-nginx and redirected to the istio-proxy container of one python pod, which then redirects it to the python container.

What happened here?

Images 1–5 display the same example Kubernetes application with nginx and python pods. We have seen how a request happens using default Kubernetes services and then using Istio.

The important thing: whatever method is used, the result is the same and the application itself doesn’t need to be changed, only the infrastructure code.

Why all this, why using Istio?

If nothing has changed when using Istio (the nginx pods can still connect to python pods just as before) why use Istio then in the first place?

The amazing advantage is that now all traffic is routed over a istio-proxy container in every pod. Whenever an istio-proxy receives and redirects a request it also submits information about it to the Istio Control Plane.

Hence the Istio Control Plane knows exactly from which pod the request came, which HTTP headers were present, how long a request from one istio-proxy to another took and much more. In a cluster with many services communicating with each other, this allows for more observability and better control over all traffic.

Advanced Routing

Kubernetes internal services can only do round-robin or random distribution of service requests to pods. With Istio much more complex ways are possible. Like redirecting depending on request headers, if errors occurred or to the service least used.

Deployments

It allows routing certain percentages of traffic to certain service versions and hence allows for Green/Blue and Canary deployments.

Encryption

Cluster internal traffic between pods, from istio-proxy to istio-proxy , can be encrypted.

Monitoring / Graph generation

Istio connects to monitoring tools like Prometheus. It also works great with Kiali to display all services and their traffic out of the box.

Tracing

Because the Istio Control Plane has loads of data about requests, these can be traced and inspected with for example Jaeger.

Multi cluster mesh

Istio has an internal service registry which can use existing Kubernetes services. Though it’s also possible to add resources from outside the cluster or even connect different clusters into one mesh.

Sidecar Injection

For Istio to work every pod which should be part of the mesh needs to have the istio-proxy sidecar injected. This can be done automatically for whole namespaces during pod creation (via Admission Controller Hook) or done manually.

Does Istio replace Kubernetes services?

No. One question I asked myself when I began with Istio was if it would replace existing Kubernetes services. The answer is no. Istio uses existing Kubernetes services to get all their endpoints/pod IP addresses.

Does Istio replace Kubernetes Ingress?

(Maybe read into Ingress in part 2 of this series)

Yes. Istio provides new resources, like Gateway and VirtualService, and even comes with the ingress converter istioctl convert-ingress . A good source is https://istio.io/docs/concepts/traffic-management