Not Only Kubernetes

Integration is far less complex than it sounds at first. Up front, Istio currently supports operations with Kubernetes out of the box but is not hard-wired to Kubernetes forever (Figure 1). Support for Mesosphere, for example, is in the planning stage, because Istio doesn't use any features that exist only and exclusively in Kubernetes. Because practically nobody uses plain vanilla Kubernetes but, rather, relies on one of the existing Kubernetes distributions, it is important that Istio also adapt to them.

Figure 1: Istio currently still prefers to address Kubernetes users and interacts with many Kubernetes variants, as here in Amazon Web Services.

Currently, Istio can be rolled out with Minikube, as well as with Google Kubernetes Engine or OpenShift. Istio also natively supports Kubernetes clusters in Amazon Web Services (AWS); just load the Istio ruleset into an existing Kubernetes cluster and add the Istio pod definitions – all done. The Istio functionality can now be used in Kubernetes, but how exactly does this work in practice?

Control and Data Planes

If you look at a common Istio deployment, you will be reminded of classic network switches. Istio divides a mesh (i.e., the entire virtual network topology between the components of a microservice architecture app) into two levels: The control plane contains the entire logic for controlling all data streams, and the data plane implements those data streams and ensures that they follow the rules defined in the policy.

Unfortunately, the Istio developers could not resist the temptation to invent a multitude of Istio-specific terms. If you are not used to working with Istio, the names can be very confusing – although most components in Istio perform tasks for which there are clearly named role models in IT.

One example of this is Envoy proxies, a type of sidecar that Istio uses to support containers. A sidecar in Istio is simply any technical device that is welded onto an existing container to provide it with a service.

An Envoy proxy is just one specific sidecar type that tells the Istio rulebook to route all incoming and outgoing traffic. As instructed by Istio, Kubernetes always rolls out the proxies as part of a pod, along with the workload container, and configures the structure so that the proxy is basically a man-in-the-middle for its containers.

Focus on Envoys

Envoy proxies (for simplicity's sake, mostly referred to as Envoys in Istio-speak) are multitalented. As the only component of the setup, the Envoy proxy is written in C++. Compared with a solution in Go, the Istio developers expect performance advantages, although Go is more in keeping with the zeitgeist. Envoys therefore manipulate the host's netfilter rules such that they gain access to all the traffic of the container in whose pod they are rolled out.

The main task of the Envoy proxies is not to change this traffic. Initially, they just measure it. Acquiring telemetry data is absolutely necessary for the functionality of Istio, because without a usable numeric base, it would be impossible to carry out load balancing that reflects actual access or to add or remove instances of existing load balancers as required.

Envoys do not handle these tasks directly. Instead, this is where the control plane comes into play – more specifically, a service that is, in a way, the brain of an Istio installation: Mixer.