This demo accompanies a GCP Blog Post on managing application deployments with Istio and Stackdriver.
In this example, we will learn 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.
- Setup
- Deploy the Sample App
- Deploy ProductCatalog v2
- Observe Latency with Stackdriver
- Rollback
- Cleanup
- Learn More
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:
- From Cloud Shell, enable the Kubernetes Engine API.
gcloud services enable container.googleapis.com
- Create a GKE cluster:
gcloud beta container clusters create istio-canary \
--zone=us-central1-f \
--machine-type=n1-standard-2 \
--num-nodes=4
- Change into the Istio install directory from the root of this repository.
cd common/
- Install Istio on the cluster:
./install_istio.sh
- Once the cluster is ready, ensure that Istio is running:
$ kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-556b649566-fw67z 1/1 Running 0 5m24s
istio-ingressgateway-fc6c9d9df-nmndg 1/1 Running 0 5m30s
istio-tracing-7cf5f46848-qksxq 1/1 Running 0 5m24s
istiod-7b5d6db6b6-b457p 1/1 Running 0 5m48s
kiali-b4b5b4fb8-hwm42 1/1 Running 0 5m23s
prometheus-558b665bb7-5v647 2/2 Running 0 5m23s
- Deploy the microservices-demo application, and add a
version=v1
label to theproductcatalog
deployment
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/kubernetes-manifests.yaml
kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/master/release/istio-manifests.yaml
kubectl delete serviceentry allow-egress-google-metadata
kubectl delete serviceentry allow-egress-googleapis
kubectl patch deployments/productcatalogservice -p '{"spec":{"template":{"metadata":{"labels":{"version":"v1"}}}}}'
- Using
kubectl get pods
, verify that all pods areRunning
andReady
.
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
cd
into the example directory.
cd istio-canary-gke/
- Create an Istio DestinationRule for
productcatalogservice
.
kubectl apply -f canary/destinationrule.yaml
- Deploy
productcatalog
v2.
kubectl apply -f canary/productcatalog-v2.yaml
- Using
kubectl get pods
, verify that thev2
pod is Running.
productcatalogservice-v2-79459dfdff-6qdh4 2/2 Running 0 1m
- Create an Istio VirtualService to split incoming
productcatalog
traffic between v1 (75%) and v2 (25%).
kubectl apply -f canary/vs-split-traffic.yaml
- In a web browser, navigate again to the hipstershop frontend.
- 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.
- Open the Kiali dashboard.
istioctl dashboard kiali &
-
Navigate to Service Graph > namespace:
default
-
Select "Versioned App Graph."
-
In the service graph, zoom in on
productcatalogservice
. You should see that approximately 25% of productcatalog requests are going tov2
.
- Navigate to Stackdriver Monitoring.
- Create a Stackdriver Workspace for your GCP project (instructions).
- From your new Stackdriver Workspace, navigate to Resources > Metrics Explorer. in the left sidebar.
-
From Metrics Explorer, enter the following parameters on the left side of the window:
- Resource type: Kubernetes Container
- Metric: Server Response Latencies (
istio.io/service/server/response_latencies
) - Group by:
destination_workload_name
- Aggregator: 50th percentile
-
In the menubar of the chart on the right, choose the Line type.
-
Once the latency chart renders, you should see
productcatalog-v2
as an outlier, with mean latencies hovering at 3 seconds. This is the value ofEXTRA_LATENCY
we injected into v2.
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.
- Return 100% of
productcatalog
traffic tov1
:
kubectl apply -f canary/rollback.yaml
- 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-canary --zone us-central1-f
- Incremental Istio Part 1, Traffic Management (Istio blog)
- Canary Deployments using Istio (Istio blog)
- Drilling down into Stackdriver Service Monitoring (GCP blog)