Playing with Istio

Istio is a Service Mesh, which is another term for: a network of containerized applications working together to discover, measure, manage, load balance, monitor and possibly recover your application. In the setup which follows, we’ll go through the process of starting a GKE cluster and deploying a sample application connected through an Istio sidecar.

This article intends to give you an understanding of what it takes to run your Kubernetes applications injected with Istio instrumentation. In future posts we’ll get further into the details of building upon this base of knowledge. So lets get the configurations out of the way first.

Download and install Istio for your operating system. If you’re installing on windows be sure to get the archive which contains the examples, we’ll be using them later.

As your Kubernetes depoyments get more and more complex, you’re going to need a Service Mesh like Istio to both give you insights into operations and to manage your applications. In this post we’ll move a bit faster from a setup standpoint, having benefited from our earlier work in Terraforming K8S Cluster creation and it’s prerequisite posts.

I’ll be following Google’s Istio Install instructions, and have described below the configuration i’m using to create my Istio cluster in GKE. You can follow along or try your own configuration using Terraform or YAML scripting.

You might be wondering what all this new configuration and sidecar setup is doing for us. To that end, lets take a deeper look into what a sidecar is and what capabilities they’ll add to our projects.

In our earlier posts on Kubernetes, we talked about a 1 to 1 relationship between pods and containers, while this is generally the case there are patterns where two or more containers may collaborate within a pod. The sidecar pattern is one such example. Istio is a sidecar container which essentially injects service mesh capabilities into your application container which aren’t there by default. It accomplishes this by creating a proxy between your container and the Kubernetes control plane when your container is started. The Pilot manages and configures the proxies to route traffic. Kubernetes will also configure Mixers to enforce policies and collect telemetry. The Citadel can be configured to provide secure transports between services.

The main purpose of the Istio sidecar is to provide your container with service mesh capabilities such as: logging, monitoring, telemetry, instrumentation and more without you having to customize them in your application container. You leverage Kubernetes standards and best practices which have been hardened and tested in PROD, by many other applications. Hopefully by now your cluster is created and running.

After your cluster has been started, click on Services and Gateways to see the Istio Service Pods and Ingress Gateway running.

We can now cut over from the Google Istio Install procedure we were following to the Istio Getting Started procedure to launch a demo app. We’ll be going through those steps below, the getting started link is provided for more detailed reference.

Istio provides several configuration profiles to help get started, eventually you’ll create your own profile. To get started we’ll be using the Demo profile, which will give us access to the largest set of potential Services we may want to use. Istio profiles provide customization of the Istio control plane and to the sidecars in the Istio data plane, that are necessary when your application configurations become more complex.

While Demo provides the greatest potential set of services, Default provides the least options and may be more appropriate for a PROD environment. This is something you’ll need to consider when you decide to leave our sandbox environment and need to think harder about securing your applications.

If you haven’t already done so, change your directory to the Root where you installed Istio and the samples. On my Windows 10 laptop I installed in my C:\Tools directory. Our next configurations will be relative to this location and use the provided YAML configurations in that folder.

# deploy istio sample application
$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
service/details created
serviceaccount/bookinfo-details created
deployment.apps/details-v1 created
service/ratings created
serviceaccount/bookinfo-ratings created
deployment.apps/ratings-v1 created
service/reviews created
serviceaccount/bookinfo-reviews created
deployment.apps/reviews-v1 created
deployment.apps/reviews-v2 created
deployment.apps/reviews-v3 created
service/productpage created
serviceaccount/bookinfo-productpage created
deployment.apps/productpage-v1 created

You will notice that the sample Book application should start. As each pod becomes ready, the Istio sidecar will deploy along with it. The unique names and possibly the cluster IP address will be different for you.

To run the Verification step described in the Istio Getting started guide, you’ll need a Linux shell. But, if you’re running from Windows 10 like I am you’ll have better luck using a Git Bash shell. I’m assuming you have Git installed, otherwise this might be a good place to stop (developer humor ha ha, why else would you be reading this).

We’re almost ready to test our sample application from the browser, but first we’ll need to determine how to reach it running inside the GKE cluster. If you’re on Windows, run these commands form Git Bash. You can cheat and look for the IP address of the istio-ingressgateway in the browser on the Services & Ingress page, but you’ll need these environment variables later when you open the Kiali browser tab from your shell.

You should now be able to reach the product page through the gateway url. Your IP address will be different than mine, and mine will be destroyed after I complete the cleanup, but the url should look like the one below.

You can now get a sense for some default monitoring provided by the sidecar using Kiali. Kiali is a console for Istio with service mesh configuration capabilities. Lets go ahead and open a browser tab to Kiali, login using user admin and password admin.

# open browser to kiali
istioctl dashboard kiali

Your basic setup is now complete, you should be able to navigate through some of the screens in Kiali to get a better sense for default monitoring capabilities you can get from Istio out-of-the-box. Don’t be disappointed if you don’t see the graph page the getting started document shows, it has a dependency on Prometheus that the default install didn’t provide for us.

Mitch is a Thought Leader and an Architect at Steampunk where he contributes to delivering human-centered, secure digital, platforms.
His work related interests span the gamut of: application integration, scalable secure clusters, embedded systems, and user interfaces. After hours you might find him dabbling in the hobby space with Raspberry Pi's, drones, photography, home wine making and other ferments.

Published by Mitch Dresdner

Mitch is a Thought Leader and an Architect at Steampunk where he contributes to delivering human-centered, secure digital, platforms.
His work related interests span the gamut of: application integration, scalable secure clusters, embedded systems, and user interfaces. After hours you might find him dabbling in the hobby space with Raspberry Pi's, drones, photography, home wine making and other ferments.
View more posts