What is Kubernetes Istio?

Istio is a platform used to interconnect microservices. It provides advanced network features like load balancing, service-to-service authentication, monitoring, etc, without requiring any changes in service code.

In the Kubernetes context, Istio deploys an Envoy proxy as a sidecar container inside every pod that provides a service.

These proxies mediate every connection, and from that position they route the incoming / outgoing traffic and enforce the different security and network policies.

This dynamic group of proxies is managed by the Istio “control plane”, a separate set of pods that orchestrate the routing, security, live ruleset updates, etc.

Service mesh explained: The rise of the “service mesh”

Containers are incredibly light and fast, it’s no surprise their density is roughly one order of magnitude greater than virtual machines. Classical monolithic component interconnection diagrams are rapidly turning into highly dynamic, fault tolerant, N-to-N communications with their own internal security rules, labeling-based routes, DNS and service directories, etc. The famous microservice mesh.

This means that while software autonomous units (containers) are becoming simpler and numerous, interconnection and troubleshooting distributed software behavior is actually getting harder.

And of course, we don’t want to burden containers with this complexity, we want them to stay thin and platform agnostic.

Kubernetes already offers a basic abstraction layer separating the service itself from the server pods. Several software projects are striving to tame this complexity, offering visibility, traceability and other advanced pod networking features.

Istio features overview

• Intelligent routing and load balancing: Policies to map static service interfaces to different backend versions, allowing for A/B testing, canary deployments, gradual migration, etc. Istio also allows you to define routing rules based on HTTP-layer metadata like session tokens or user agent string.
• Network resilience and health checks: timeouts, retry budgets, health checks and circuit breakers. Ensuring that unhealthy pods can be quickly weeded out of the service mesh
• Policy Enforcement: Peer TLS authentication, pre-condition checking (whitelists and similar ACL), quota management to avoid service abuse and/or consumer starvation.
• Telemetry, traceability and troubleshooting: telemetry is automatically injected in any service pod providing Prometheus-style network and L7 protocol metrics, Istio also dynamically traces the flow and chained connections of your microservices mesh.

How to deploy Istio in Kubernetes

Istio deployment overview

Istio developers have made deploying the platform in a new or existing Kubernetes cluster simple enough.

Just make sure that your Kubernetes version is 1.7.3 or newer, with RBAC enabled. And that you don’t have any older version of Istio already installed on the system.

Following the installation instructions here:

curl -L https://git.io/getLatestIstio | sh -
cd istio-<version>
export PATH=$PWD/bin:$PATH

Now you need to decide whether or not you want mutual TLS authentication between pods. If you choose to enable TLS your Istio services won’t be allowed to talk to non-Istio entities.

We will use the non-TLS version this time:

kubectl apply -f install/kubernetes/istio.yaml

Istio system services and pods will be ready in a few minutes:

$ kubectl get svc -n istio-system
NAME            CLUSTER-IP      EXTERNAL-IP      PORT(S)                                                            AGE
istio-ingress   10.15.240.67    some-external-ip   80:32633/TCP,443:31389/TCP                                         1d
istio-mixer     10.15.249.77    <none>           9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP   1d
istio-pilot     10.15.243.227   <none>           15003/TCP,443/TCP                                                  1d

$ kubectl get pod -n istio-system
NAME                             READY     STATUS    RESTARTS   AGE
istio-ca-1363003450-vp7pt        1/1       Running   0          1d
istio-ingress-1005666339-w1gcs   1/1       Running   0          1d
istio-mixer-465004155-nncrd      3/3       Running   0          1d
istio-pilot-1861292947-zlt8w     2/2       Running   0          1d

Injecting the Istio “Envoy” proxy in your existing Kubernetes pods

As we mentioned in the architecture diagram, any service pod needs to be bundled with the Envoy container. Your Kubernetes cluster can be automatically instructed to do it if the alpha cluster features are enabled and you deploy the Istio-initializer:

kubectl apply -f install/kubernetes/istio-initializer.yaml

Alternatively, you can rewrite your existing yaml definitions on the fly using istioctl

kubectl create -f <(istioctl kube-inject -f <your-app-spec>.yaml)

Let’s try with a simple single container deployment and service.

$ kubectl apply -f <(istioctl kube-inject -f flask.yaml)
$ kubectl logs flask-1027288086-lr4fm
a container name must be specified for pod flask-1027288086-lr4fm, choose one of: [flask istio-proxy]

Ok, it looks like our pods and services have been correctly instrumented.