Istio on IBM Cloud

When organizations move to microservices, they need to support dozens or hundreds of specific applications. Managing those endpoints separately means supporting a large number of virtual machines (VMs), including demand. Cluster software like Kubernetes can create pods and scale them up, but Kubernetes does not provide routing, traffic rules, or strong monitoring or debugging tools.

Enter the service mesh.

As the number of services increases, the number of potential ways to communicate increases exponentially. Two services have only two communication paths. Three services have six, while 10 services have 90. A service mesh provides a single way to configure those communications paths by creating a policy for the communication.

A service mesh instruments the services and directs communications traffic according to a predefined configuration. Instead of configuring a running container, or writing code to do so, an administrator can provide configuration to the service mesh and have it complete that work. Previously, this had to happen with web servers and service-to-service communication.

The most common way to do this in a cluster is to use the sidecar pattern. A sidecar is a new container, inside the pod, that routes and observes communications traffic between services and containers.

Istio layers on top of Kubernetes, adding containers that are essentially invisible to the programmer and administrator. Called sidecar containers, these act as a "person in the middle," directing traffic and monitoring the interactions between components. The two work in combination in the following three ways.

Configuration: The primary method to set configuration with Kubernetes is the kubectl command, commonly kubectl -f <filename>, where the file is a YAML file. Istio users can either run new and different types of YAML files with kubectl or use the new, optional, ioctl command.

Monitoring: With Istio, you can monitor the health of your applications running with Kubernetes. Istio instrumentation can manage and visualize the health of applications, providing more insight than the general monitoring of cluster and nodes that Kubernetes provides.

Management: Because the interface for Istio is essentially the same as Kubernetes, managing it takes little additional work. Istio allows the user to create policies that impact and manage the entire Kubernetes cluster, reducing time to manage each cluster while eliminating the need for custom management code.

Istio uses a heavily extended version of Envoy to perform the monitoring, management and logging. Every pod needs to be tracked, and Istio needs to aggregate and provide information about all of the pods. One possible alternative to using Istio would be to deploy Envoy into the Kubernetes cluster directly and write management code. This is essentially recreating Istio, with the associated costs and bugs of a custom development project.