This document demonstrates upgrading Istio in a way that allows operators to be in control of the transition of workloads from one version to the next.
This document is an adaptation of the document entitled Canary Upgrades from the official Istio documentation.
The BookInfo sample application will serve as the workload under test.
Feature status of Revision Based Upgrades is alpha
In this exercise, we will:
- Install a Kubernetes cluster
- Install Istio v1.12.5
- Deploy the BookInfo sample application to the
- Install Istio v1.13.2, triggering solely the upgrade of the ingress gateway (not the workloads)
- Demonstrate namespace labeling as the mechanism for controlling the desired version of Istio to use for workloads in that namespace.
- Teardown previous version of Istio, completing the upgrade.
Finally, we will demonstrate an alternative to labeling namespaces directly, by using what Istio calls Revision Tags.
In the instructions that follow, I use GCP as my infastructure, but feel free to use any Kubernetes you like.
Create a K8s Cluster¶
Wait until cluster is ready.
In a workspace directory of your choice, download two Istio releases, 1.12.5 and 1.13.2.
Be sure to use the hardware architecture matching your workstation:
Setting your PATH¶
I use direnv to easily update my PATH so that istioctl points to version 1.12.5 or version 1.13.2 as a function of the directory that i navigate to.
Given a file named
.envrc in the folder
I can run
direnv allow, and note that running
istioctl version from that directory returns
Likewise, the same file in the
istio-1.13.2 directory allows me to quickly switch to that version.
Check the ingressgateway Istio version:
Label the default namespace¶
Open a browser and visit the BookInfo product page (at
Verifying that workloads use version 1.12.5¶
Checking the server_info endpoint of a sidecar:
And check that the ANNOTATIONS revision is 1-12-5
Describe the pod
Make sure your PATH now points to version 1.13.2 of the
Install Istio version 1.13.2¶
- Both 1-13-2 and 1-12-5 istiod's are installed
- ingressgateway has been upgraded to 1.13.2
- Pods still use 1-12-5
Update namespace label¶
Restart the deployments in the default namespace¶
Teardown the old version¶
Verify that the bookinfo application is still alive and well.
Using Revision Tags¶
Instead of specifying the actual revision we want, we use a semantic name, like
And then associate prod to a revision:
To change what prod means, we associate a different revision to it:
What about the Gateways?¶
Gateways can be canary-ugraded instead of using in-place upgrades.
Here's an outline of the recipe:
- Install istiod by itself (no gateway) by using the minimal profile.
- Install the gateway separately by using the empty profile.
- Can canary-deploy the gateway by creating a second deployment, and labeling the deployment with
istio.io/revto control which sidecar version is bundled into the pod.
- This is explained in more detail here.
- Operators can make available a new version of Istio and notify developers to update their workloads on their own time.
- Develop a process, and automation for implementing Istio ugprades, and rollbacks. Start by listening to Pratima Nambiar from Salesforce in her Istio Community Talk.