Upgrade with Helm

Follow this guide to upgrade and configure an Istio mesh using Helm for in-depth evaluation. This guide assumes you have already performed an installation with Helm for a previous minor or patch version of Istio.

The Helm charts used in this guide are the same underlying charts used when installing Istio via Istioctl or the Operator.

This feature is currently considered alpha.

Prerequisites

1. Download the Istio release.

2. Perform any necessary platform-specific setup.

3. Check the Requirements for Pods and Services.

4. Install a Helm client with a version higher than 3.1.1.

The commands in this guide use the Helm charts that are included in the Istio release package located at manifests/charts.

Upgrade steps

Change directory to the root of the release package and then follow the instructions below.

Before upgrading Istio, it is recommended to run the istioctl x precheck command to make sure the upgrade is compatible with your environment.

$ istioctl x precheck
✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
To get started, check out https://istio.io/latest/docs/setup/getting-started/

Create a backup

Before upgrading Istio in your cluster, we recommend creating a backup of your custom configurations, and restoring it from backup if necessary:

$ kubectl get istio-io --all-namespaces -oyaml > "$HOME"/istio_resource_backup.yaml

You can restore your custom configuration like this:

$ kubectl apply -f "$HOME"/istio_resource_backup.yaml

Canary upgrade (recommended)

You can install a canary version of Istio control plane to validate that the new version is compatible with your existing configuration and data plane using the steps below:

1. Upgrade the Kubernetes custom resource definitions (CRDs):

   $ kubectl apply -f manifests/charts/base/crds
   

2. Install a canary version of the Istio discovery chart by setting the revision value:

   $ helm install istiod-canary manifests/charts/istio-control/istio-discovery \
       --set revision=canary \
       -n istio-system
   

3. Verify that you have two versions of istiod installed in your cluster:

   $ kubectl get pods -l app=istiod -L istio.io/rev -n istio-system
     NAME                            READY   STATUS    RESTARTS   AGE   REV
     istiod-5649c48ddc-dlkh8         1/1     Running   0          71m   default
     istiod-canary-9cc9fd96f-jpc7n   1/1     Running   0          34m   canary
   

4. Follow the steps here to test or migrate existing workloads to use the canary control plane.

5. Once you have verified and migrated your workloads to use the canary control plane, you can uninstall your old control plane:

   $ helm delete istiod -n istio-system
   

6. Upgrade the Istio base chart:

   $ helm upgrade istio-base manifests/charts/base -n istio-system --skip-crds
   

Stable revision labels (experimental)

Usage

$ helm template istiod manifests/charts/istio-control/istio-discovery -s templates/revision-tags.yaml --set revisionTags={prod-stable} --set revision=1-9-5 -n istio-system | kubectl apply -f -
$ helm template istiod manifests/charts/istio-control/istio-discovery -s templates/revision-tags.yaml --set revisionTags={prod-canary} --set revision=1-10-0 -n istio-system | kubectl apply -f -

The resulting mapping between revisions, tags, and namespaces is as shown below:

The cluster operator can view this mapping in addition to tagged namespaces through the istioctl tag list command:

$ istioctl tag list
TAG         REVISION NAMESPACES
prod-canary 1-10-0   ...
prod-stable 1-9-5    ...

After the cluster operator is satisfied with the stability of the control plane tagged with prod-canary, namespaces labeled istio.io/rev=prod-stable can be updated with one action by modifying the prod-stable revision tag to point to the newer 1-10-0 revision.

$ helm template istiod manifests/charts/istio-control/istio-discovery -s templates/revision-tags.yaml --set revisionTags={prod-stable} --set revision=1-10-0 -n istio-system | kubectl apply -f -

Now, the situation is as below:

Restarting injected workloads in the namespaces marked prod-stable will now result in those workloads using the 1-10-0 control plane. Notice that no namespace relabeling was required to migrate workloads to the new revision.

Default tag

The revision pointed to by the tag default is considered the default revision and has additional semantic meaning.

The default revision will inject sidecars for the istio-injection=enabled namespace selector and sidecar.istio.io/inject=true object selector in addition to the istio.io/rev=default selectors. This makes it possible to migrate from using non-revisioned Istio to using a revision entirely without relabeling namespaces. To make a revision 1-10-0 the default, run:

$ helm template istiod manifests/charts/istio-control/istio-discovery -s templates/revision-tags.yaml --set revisionTags={default} --set revision=1-10-0 -n istio-system | kubectl apply -f -

In place upgrade

You can perform an in place upgrade of Istio in your cluster using the Helm upgrade workflow.

1. Upgrade the Kubernetes custom resource definitions (CRDs):

   $ kubectl apply -f manifests/charts/base/crds
   

2. Upgrade the Istio base chart:

   $ helm upgrade istio-base manifests/charts/base -n istio-system --skip-crds
   

3. Upgrade the Istio discovery chart:

   $ helm upgrade istiod manifests/charts/istio-control/istio-discovery \
       -n istio-system
   

4. (Optional) Upgrade the Istio ingress or egress gateway charts if installed in your cluster:

   $ helm upgrade istio-ingress manifests/charts/gateways/istio-ingress \
       -n istio-system
   $ helm upgrade istio-egress manifests/charts/gateways/istio-egress \
       -n istio-system
   

Uninstall

Please refer to the uninstall section in our Helm install guide.