Upgrade with Helm

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

The Helm charts for base and istiod used in this guide are the same as those used when installing Istio via Istioctl or the Operator. However installations via Istioctl and the Operator use a different gateway chart to the chart described in this guide

Prerequisites

  1. Perform any necessary platform-specific setup.

  2. Check the Requirements for Pods and Services.

  3. Install the Helm client, version 3.6 or above.

  4. Configure the Helm repository:

  1. $ helm repo add istio https://istio-release.storage.googleapis.com/charts
  2. $ helm repo update

Upgrade steps

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

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

Helm does not upgrade or delete CRDs when performing an upgrade. Because of this restriction, an additional step is required when upgrading Istio with Helm.

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:

Note that when you install a canary version of the istiod service, the underlying cluster-wide resources from the base chart are shared across your primary and canary installations.

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

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

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

    1. $ helm install istiod-canary istio/istiod \
    2.     --set revision=canary \
    3.     -n istio-system

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

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

  4. If you are using Istio gateways, install a canary revision of the Gateway chart by setting the revision value:

    1. $ helm install istio-ingress-canary istio/gateway \
    2.     --set revision=canary \
    3.     -n istio-ingress

  5. Verify that you have two versions of istio-ingress gateway installed in your cluster:

    1. $ kubectl get pods -L istio.io/rev -n istio-ingress
    2.   NAME                                    READY   STATUS    RESTARTS   AGE     REV
    3.   istio-ingress-754f55f7f6-6zg8n          1/1     Running   0          5m22s   default
    4.   istio-ingress-canary-5d649bd644-4m8lp   1/1     Running   0          3m24s   canary

    See Upgrading Gateways for in-depth documentation on gateway canary upgrade.

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

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

    1. $ helm delete istiod -n istio-system

  8. Upgrade the Istio base chart, making the new revision the default.

    1. $ helm upgrade istio-base istio/base --set defaultRevision=canary -n istio-system --skip-crds

Stable revision labels

Manually relabeling namespaces when moving them to a new revision can be tedious and error-prone. Revision tags solve this problem. Revision tags are stable identifiers that point to revisions and can be used to avoid relabeling namespaces. Rather than relabeling the namespace, a mesh operator can simply change the tag to point to a new revision. All namespaces labeled with that tag will be updated at the same time.

Usage

Consider a cluster with two revisions installed, 1-22-1 and 1-23-3. The cluster operator creates a revision tag prod-stable, pointed at the older, stable 1-22-1 version, and a revision tag prod-canary pointed at the newer 1-23-3 revision. That state could be reached via the following commands:

  1. $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-stable}" --set revision=1-22-1 -n istio-system | kubectl apply -f -
  2. $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-canary}" --set revision=1-23-3 -n istio-system | kubectl apply -f -

These commands create new MutatingWebhookConfiguration resources in your cluster, however, they are not owned by any Helm chart due to kubectl manually applying the templates. See the instructions below to uninstall revision tags.

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

Two namespaces pointed to prod-stable and one pointed to prod-canary
Two namespaces pointed to prod-stable and one pointed to prod-canary

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

  1. $ istioctl tag list
  2. TAG         REVISION NAMESPACES
  3. default     1-22-1   ...
  4. prod-canary 1-23-3   ...
  5. prod-stable 1-22-1   ...

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-23-3 revision.

  1. $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-stable}" --set revision=1-23-3 -n istio-system | kubectl apply -f -

Now, the updated mapping between revisions, tags, and namespaces is as shown below:

Namespace labels unchanged but now all namespaces pointed to {{< istio_full_version_revision >}}
Namespace labels unchanged but now all namespaces pointed to {{< istio_full_version_revision >}}

Restarting injected workloads in the namespaces marked prod-stable will now result in those workloads using the 1-23-3 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 performs the following functions:

  • Injects sidecars for the istio-injection=enabled namespace selector, the sidecar.istio.io/inject=true object selector, and the istio.io/rev=default selectors
  • Validates Istio resources
  • Steals the leader lock from non-default revisions and performs singleton mesh responsibilities (such as updating resource statuses)

To make a revision 1-23-3 the default, run:

  1. $ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{default}" --set revision=1-23-3 -n istio-system | kubectl apply -f -

When using the default tag alongside an existing non-revisioned Istio installation it is recommended to remove the old MutatingWebhookConfiguration (typically called istio-sidecar-injector) to avoid having both the older and newer control planes attempt injection.

In place upgrade

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

Add your override values file or custom options to the commands below to preserve your custom configuration during Helm upgrades.

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

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

  2. Upgrade the Istio base chart:

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

  3. Upgrade the Istio discovery chart:

    1. $ helm upgrade istiod istio/istiod -n istio-system

  4. (Optional) Upgrade and gateway charts installed in your cluster:

    1. $ helm upgrade istio-ingress istio/gateway -n istio-ingress

Uninstall

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