This is the second day of my participation in Gwen Challenge

Istio is a service grid that allows for more detailed, complex, and observable communication between Pods and services in a cluster.

It is managed by using the CRD extension Kubernetes API, which injects the proxy container into all pods, which then control the traffic in the cluster

Kubernetes Services

We can use a brief explanation of how to implement Kubernetes Services to help understand how Istio works.

Figure 1: Kubernetes Native Service Request

The Kubernetes cluster above has two nodes and four pods, each with a container. The service service-nginx points to Nginx Pods, and the service service-python points to Python Pods. The red line shows requests from the Nginx container in POD1-nginx to the service-Python service, which redirects requests to Pod2-Python.

By default, the ClusterIP service makes simple random or polling forward requests, and the Services in Kubernetes do not exist on specific nodes, but on the entire cluster. We can see more details in the image below:

Figure 2: Kubernetes native Service Request with Kube-proxy

To be more detailed in the figure above, the services in Kubernetes are implemented by the Kube-Proxy component running on each node, which creates iptables rules and redirects requests to pods. Therefore, a service is an Iptables rule. (There are other proxy patterns that do not use Iptables, but the process is the same.)

Kubernetes Istio

Now let’s look at the same example with Istio configured:

Figure 3: Istio Control Plane Programs ISTIO-proxy

In the figure above, you can see that Istio is installed in the cluster. Each pod has a second Sidecar container called isTIo-Proxy that is automatically injected into the Pods during creation.

The most common proxy for Istio is Envoy, but other proxies (such as Nginx) can also be used, so we call the proxy ISTIo-proxy.

We can see that the Kube-Proxy component is no longer displayed, in order to keep the image clean. These components still exist, but the Pods with Istio-Proxy will no longer use the Kube-Proxy component.

The Istio control plane processes all isTIO-Proxy sidecars whenever configuration or service changes, similar to how the Kube-Proxy components are handled by the Kubernetes API in Figure 2. The Istio control plane uses the existing Kubernetes service to receive all Pods pointed to by each service point, and Istio implements its own routing by using pod IP addresses.

After the Istio control plane processes all the ISTIO-proxy sidecars, it looks like this:

Figure 4: Istio Control Plane programmed all isTIo-proxys

In Figure 4, we see how the Istio control plane applies the current configuration to all isTIO-Proxy containers in the cluster, and Istio converts the Kubernetes service declarations into its own routing declarations.

Let’s look at how to make a request using Istio:

Figure 5: Request made with Istio

In the figure above, all isTIo-proxy containers are controlled by the ISTIO control plane and contain all necessary routing information. As shown in Figure 3/4, the Nginx container from POd1-nginx makes requests to service-Python.

The request is intercepted by the POd1-nginx istio-proxy container and redirected to a Python POD istio-proxy container, which then redirects the request to the Python container.

What happened?

Figure 1-5 shows the same example of a Kubernetes application using Nginx and Python Pod, and we have seen how requests occur using the default Kubernetes service and using Istio.

The important thing is that the result is the same no matter what method you use, and you don’t need to change the application itself, just the infrastructure code.

Why Istio?

If nothing changes when Istio is used (Nginx Pods can still connect to Python Pods as before), then why use Istio at all?

The amazing advantage is that all traffic is now routed through the ISTIO-Proxy container in each Pod, and every time ISTIo-Proxy receives and redirects a request, it also submits information about that request to the ISTIO control plane. So the Istio control plane knows exactly which POD the request is coming from, which HTTP headers exist, how long the request takes to get from one ISTIO-proxy to another, and so on. In a cluster with services that communicate with each other, this improves visibility and provides better control over all traffic.

With advanced routing, Kubernetes internal Services can only poll pods or randomly distribute requests, but Istio allows for a more sophisticated approach. For example, if an error occurs, redirect to the request header or to the least-used service.

Deployment, which allows a percentage of traffic to be routed to a particular version of the service, thus allowing green/blue and Canary deployment.

Encryption: Encrypts intra-cluster communication between Pods from ISTIo-proxy to ISTIo-proxy.

Monitoring/graphics, Istio can be connected to monitoring tools such as Prometheus or can be used with Kiali to show all services and their traffic.

Tracing, because the Istio control plane has a lot of data about requests, you can use tools like Jaeger to track and examine this data.

** Multiple cluster mesh, **Istio has an internal service registry that can use existing Kubernetes services, but can also add resources from outside the cluster or even connect different clusters to a grid.

Sidecar injection. In order for Istio to work, each pod that is part of the mesh needs to inject an ISTIo-proxy Sidecar, which can be done automatically (or manually) for the entire namespace during pod creation.

Will Istio replace Kubernetes’ service?

Of course not, one of the questions I asked myself when I started using Istio was whether it would replace the existing Kubernetes service, and the answer was no, because Istio would use the existing Kubernetes service to get all their Endpoints/Pod IP addresses.

Did Istio replace Kubernetes’ Ingress?

Yes, Istio provides new CRD resources such as Gateway and VirtualService, and even comes with the ingress converter istioctl convert-ingress. The following figure shows how the Istio Gateway handles incoming traffic. The gateway itself is an ISTIO-Proxy component.

conclusion

Istio certainly adds another level of complexity on top of Kubernetes, but for modern microservice architectures, it actually provides a simpler way to implement traceability or observability than having to implement it in the application code itself.

For more instructions on Istio, please refer to the official Istio. IO document.