Upgrading Gloo Mesh-managed Istio

Use Gloo Mesh to upgrade your Gloo Mesh-managed Istio instalations in your workload clusters.

This feature does not currently support managing existing Istio installations. Until management of the full lifecycle of Istio is supported, do not use this feature in production.

Currently, versions 1.11 and earlier of Istio are supported for Gloo Mesh-managed Istio installations.


After you install Istio using an IstioLifecycleManager CR, changes that you make to it are automatically propagated to your Istio installations. In some cases, these changes might result in updates to your control plane or gateway deployments. Gloo Mesh detects these cases and, depending on the type of change, applies the updates to the installations either in-place or via a canary upgrade. Note that you can force Gloo Mesh to always use canary upgrades by setting the spec.upgradeStrategy.alwaysUseCanaryUpgrade boolean value to true in the IstioLifecycleManager CR.

In-place upgrades

In-place upgrades are triggered when you change one of the following fields:

Canary upgrades

In a canary upgrade, Gloo Mesh installs another Istio installation (canary) alongside your active installation. Note that during a canary upgrade, the validating admissions webhook is enabled only for the canary installation to prevent issues that occur when multiple webhooks are enabled.

A canary upgrade is triggered when you change one of the following fields:

Upgrading Istio

  1. Edit the lifecycle manager CR in your management cluster.

    kubectl edit IstioLifecycleManager <installation-name> -n gloo-mesh --context $MGMT_CONTEXT
  2. Make changes to the file, and save and close the editor. Depending on what you change as noted previously, Gloo Mesh starts an in-place upgrade or a canary upgrade.

  3. Canary upgrades only: Upgrading the data plane in each workload cluster is not automated, as these upgrades require extra care in production environments. After your canary installation is installed, upgrade the data plane in each workload cluster by following these steps.

    1. Re-label your namespaces with the canary's revision so that deployments are injected with the newer proxy. To find the generated revision, you can run kubectl get IstioInstallationInstance <installation-name> -n gloo-mesh --context $REMOTE_CONTEXT1 in a workload cluster.
      kubectl label namespace <namespace> istio-injection- istio.io/rev=<new-revision>
    2. Restart your pods in the labeled namespace to trigger re-injection. For example, you can restart individual deployments with the following command.
      kubectl rollout restart deployments/<deployment> -n <namespace>
    3. A new cluster IP service is created for the canary gateways. If you created load balancers to point to the services for the previous version's gateways, update your load balancers to point to the cluster IP service for the gateways that run the canary version. For example, if you used the sample load balaner files in Step 4: Expose Istio gateways, you can edit the load balancer files to change the spec.selector.version field to the generated canary revision.
    4. To uninstall the previous installation, or if you need to uninstall the canary installation, you can edit the IstioLifecycleManager CR in the management cluster to add the installation's generated revision to the spec.uninstallRevisions list. To find the generated revision, you can run kubectl get IstioInstallationInstance <installation-name> -n gloo-mesh --context $REMOTE_CONTEXT1 in a workload cluster, and look for the status section.
      kubectl edit IstioInstallationInstance <installation-name> -n gloo-mesh --context $MGMT_CONTEXT

      Example uninstallRevisions field:

            apiVersion: admin.enterprise.mesh.gloo.solo.io/v1alpha1
            kind: IstioLifecycleManager
              name: managed-installation
              namespace: gloo-mesh
                - name: cluster-1
                - name: cluster-2
                - name: control-plane
                - 1-11