Branch: master
Find file History
Type Name Latest commit message Commit time
Failed to load latest commit information.
canary Updates instructions for Canary sample (#2) Feb 1, 2019
hipstershop Updates instructions for Canary sample (#2) Feb 1, 2019
screenshots Updates instructions for Canary sample (#2) Feb 1, 2019 Removes mTLS mode flag (#6) Feb 4, 2019

ProductCatalog Canary Deployment (GKE / Istio)


This example demonstrates how to use Istio’s Traffic Splitting feature to perform a Canary deployment on Google Kubernetes Engine.

In this sample, productcatalogservice-v2 introduces a 3-second latency into all server requests. We’ll show how to use Stackdriver and Istio together to view the latency difference between the existing productcatalog deployment and the slower v2 deployment.


Google Cloud Shell is a browser-based terminal that Google provides to interact with your GCP resources. It is backed by a free Compute Engine instance that comes with many useful tools already installed, including everything required to run this demo.

Click the button below to open the demo instructions in your Cloud Shell:

Open in Cloud Shell

Create a GKE Cluster

  1. From Cloud Shell, enable the Kubernetes Engine API.
gcloud services enable
  1. Create a GKE cluster using Istio on GKE. This add-on will provision your GKE cluster with Istio.
gcloud beta container clusters create istio-demo \
    --addons=Istio \
    --zone=us-central1-f \
    --machine-type=n1-standard-2 \
  1. Once the cluster is ready, ensure that Istio is running:
$ kubectl get pods -n istio-system

NAME                                     READY     STATUS      RESTARTS   AGE
istio-citadel-776fb85794-9gcqz           1/1       Running     0          7m
istio-cleanup-secrets-cg9b4              0/1       Completed   0          7m
istio-egressgateway-7f778c7fcf-hj9fw     1/1       Running     0          7m
istio-galley-794f98cf5f-9867s            1/1       Running     0          7m
istio-ingressgateway-56b648f9fb-mt7tb    1/1       Running     0          7m
istio-pilot-d87948784-7kfzt              2/2       Running     0          7m
istio-policy-5757c77d8f-54vsl            2/2       Running     0          7m
istio-security-post-install-bqjqq        0/1       Completed   0          7m
istio-sidecar-injector-f555db659-l5btv   1/1       Running     0          7m
istio-telemetry-85c84d85c6-qdtnm         2/2       Running     0          7m
prometheus-7c589d4989-9mgg8              2/2       Running     1          7m

Deploy the Sample App

  1. cd into the directory for this demo.
cd istio-canary-gke;
  1. Label the default namespace for Istio sidecar auto-injection:
kubectl label namespace default istio-injection=enabled
  1. Deploy the microservices-demo application using the YAML files provided in this repo.
kubectl apply -f ./hipstershop
  1. Using kubectl get pods, verify that all pods are Running and Ready.

At this point, ProductCatalog v1 is deployed to the cluster, along with the rest of the demo microservices. You can reach the Hipstershop frontend at the EXTERNAL_IP address output for this command:

kubectl get svc -n istio-system istio-ingressgateway

Deploy ProductCatalog v2

  1. Create an Istio DestinationRule for productcatalogservice.
kubectl apply -f canary/destinationrule.yaml
  1. Deploy productcatalog v2.
kubectl apply -f canary/productcatalog-v2.yaml
  1. Using kubectl get pods, verify that the v2 pod is Running.
productcatalogservice-v2-79459dfdff-6qdh4   2/2       Running   0          1m
  1. Create an Istio VirtualService to split incoming productcatalog traffic between v1 (75%) and v2 (25%).
kubectl apply -f canary/vs-split-traffic.yaml
  1. In a web browser, navigate again to the hipstershop frontend.
  2. Refresh the homepage a few times. You should notice that periodically, the frontend is slower to load. Let's explore ProductCatalog's latency with Stackdriver.

Observe Latency with Stackdriver

  1. Navigate to Stackdriver Monitoring.
  2. Create a Stackdriver Workspace for your GCP project (instructions).
  3. From your new Stackdriver Workspace, navigate to Resources > Metrics Explorer. in the left sidebar.

stackdriver sidebar

  1. From Metrics Explorer, enter the following parameters on the left side of the window:

    • Resource type: Kubernetes Container
    • Metric: Server Response Latencies (
    • Group by: destination_workload_name
    • Aligner: 50th percentile
    • Reducer: mean
    • Alignment period: 1 minute
  2. In the menubar of the chart on the right, choose the Line type.

  3. Once the latency chart renders, you should see productcatalog-v2 as an outlier, with mean latencies hovering at 3 seconds. This is the value of EXTRA_LATENCY we injected into v2.

metrics explorer

You’ll also notice that other services (such as frontend) have an irregular latency spike. This is because the frontend relies on ProductCatalog, for which 25% of requests are routing through the slower v2 deployment.

v2 latency


  1. Return 100% of productcatalog traffic to v1:
kubectl apply -f canary/rollback.yaml
  1. Finally, remove v2:
kubectl delete -f canary/productcatalog-v2.yaml


To avoid incurring additional billing costs, delete the GKE cluster.

gcloud container clusters delete istio-demo --zone us-central1-f

Learn More