Kubernetes Minikube #2 – Istio

Everyone’s talking about Istio. Let’s mess around with Kubernetes’ Minikube to show off Istio and see what all the fuss is about. We will do this by reworking the OpenShift MiniLabs A/B Deployment example to work with Istio. Once completed invoking a URL such as will alternate between the A/B versions of the application.


This tutorial will cover the following:

  • Prepare Minikube for Istio and sidecar autoinjection
  • Install Istio components
  • Create a v1/v2 application for an A/B scenario testing
  • Create an Istio RouteRule for traffic shaping between v1/v2
  • Then reflect why it was all so hard the first time



1. Launch Minikube

Start minikube as follows to ensure Istio features are enabled. Installing minikube was covered in blog #1 of this series. A script that launches minikube is located here.

# Stop/start minikube 
$ minikube stop
$ sudo minikube start \
  --vm-driver=none \
  --feature-gates=Accelerators=true \

$ kubectl api-versions | grep admissionregistration

2. Install Istio

Installation instructions for istio are at Choose the steps related to Minikube, without the mutual TLS authentication option and include the automatic injection of sidecar option. Verify the istio-system is up and running as per the Istio website instructions.

$ istioctl version
$ kubectl get pods -n=istio-system
$ kubectl get services -n=istio-system


1. Setup A/B Sample

This example creates an application called “cotd”, with two versions “cats” and “cities”. Cats shows set of cat pictures, while Cities shows images of different cities. In the next step we will create an Istio RouteRule that will shape traffic to a Cotd/Istio Ingress endpoint in a weighted fashion between the two version.

# This will create the service, pods, ingress resources in the ab namespace
$ kubectl create -f

# Check status of resources
$ kubectl get pod -n=ab
$ kubectl get service -n=ab
$ kubectl get ingress -n=ab

# Verify Istio sidecar injected 
$ echo $(kubectl get deployment cotd-v1 -n=ab -o jsonpath='{.metadata.annotations.sidecar\.istio\.io\/status}')
$ echo $(kubectl get deployment cotd-v2 -n=ab -o jsonpath='{.metadata.annotations.sidecar\.istio\.io\/status}')

# Point your Browser at this URL once all pods running
$ export COTD_URL=$(kubectl get pod -n istio-system -l istio=ingress -o 'jsonpath={.items[0].status.hostIP}'):$(kubectl get svc istio-ingress -n istio-system -o 'jsonpath={.spec.ports[0].nodePort}')
$ echo $COTD_URL

2. Create Istio RouteRule

The following istioctl command will create the traffic shaping route rule. Try this out, then make some changes to the rule and use istioctl replace to change and it confirm effects.

$ istioctl create -f
$ istioctl get routerules
$ export COTD_URL=$(kubectl get pod -n istio-system -l istio=ingress -o 'jsonpath={.items[0].status.hostIP}'):$(kubectl get svc istio-ingress -n istio-system -o 'jsonpath={.spec.ports[0].nodePort}')
$ echo $COTD_URL

$ while true; do curl -s http://$COTD_URL/item.php | grep "data/images" | awk '{print $5}'; sleep 2; done



For sure you will suffer some mild discomfort in using this 0.2x software. If things are misbehaving try recreating the istio-system pods. Launch the dashboard and inspect the istio-ingress logs. Check that /etc/resolv.conf has a valid entry, e.g.

$ kubectl delete pods --all -n=istio-system
$ minikube dashboard

Steak Knives

Knock about with the istio bookinfo example and try to reproduce some of the other routing rule scenarios as described at  .

Leave a Reply