Skip to content
You are viewing the documentation for Solo Enterprise for Istio, formerly known as Gloo Mesh (OSS APIs).

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Helm

Page as Markdown

Upgrade your ambient control and data plane components in your Solo Enterprise for Istio cluster.

Considerations

Before you upgrade your ambient components, review the following limitations and recommendations.

Revision and canary upgrade limitations

The upgrade guides in this documentation show you how to perform in-place upgrades for your Istio components, which is the recommended upgrade strategy.

CNI upgrades

In an ambient installation, the istio-cni pods are enhanced for safe in-place upgrades. When istio-cni is scheduled for removal, it determines whether an upgrade is in process by checking the value of AGENT_UPGRADE_ID in the istio-cni ConfigMap against its internal upgrade ID. If the removal is due to an upgrade, istio-cni creates a “stub” CNI plug-in in its place on the node. This stub CNI plug-in stalls any newly scheduled pods on that node, and does not allow the pods to spin up until the replacement istio-cni is up and running.

ztunnel upgrades

As Kubernetes dynamically upgrades the ztunnel deployment by restarting the old ztunnel pods, all long-lived connections on the node are dropped. You can influence the duration of the downtime with the termination grace period of the ztunnel pod, which determines the drain period. Any TCP connections that are longer than the grace period are dropped. Alternatively, you might cordon nodes and use blue/green node pools to limit the number of active pods that are in the process of upgrading.

Before you begin

  1. Verify that the minor version of the Solo distribution of Istio that you want to upgrade to is tested and supported for your Solo Enterprise for Istio version. To find the available patch versions, you can get the minor version repo URL from the Istio images built by Solo.io support article, and check the patch version builds in that repo.

  2. Check the Solo Enterprise for Istio release notes for changes from the previous version.

    Caution

    Before you proceed with the upgrade, make sure that you review the breaking changes that were introduced in this release and the impact that they have on your current environment. For more information, see the Breaking changes.
  3. Check the Istio release notes for the upgrade version to prepare for any breaking changes.

  4. Be sure to review the following known Istio version restrictions.

    Warning

    • Patch versions 1.26.0 and 1.26.1 of the Solo distribution of Istio lack support for FIPS-tagged images and ztunnel outlier detection. When upgrading or installing 1.26, be sure to use patch version 1.26.1-patch0 and later only.
    • In the Solo distribution of Istio 1.25 and later, you can access enterprise-level features by passing your Solo license in the license.value or license.secretRef field of the Solo distribution of the istiod Helm chart. The Solo istiod Helm chart is strongly recommended due to the included safeguards, default settings, and upgrade handling to ensure a reliable and secure Istio deployment. Though it is not recommended, you can pass your license key in the open source istiod Helm chart by using the --set pilot.env.SOLO_ISTIO_LICENSE_KEY field.
    • Ambient mode requires the Solo distribution of Istio version 1.22.3 or later (1.22.3-solo). Multicluster setups require the Solo distribution of Istio version 1.24.3 or later (1.24.3-solo), including the Solo distribution of istioctl.
    • In Istio 1.22.0-1.22.3, the ISTIO_DELTA_XDS environment variable must be set to false. For more information, see this upstream Istio issue. Note that this issue is resolved in Istio 1.22.4.
    • Due to a lack of support for the Istio CNI and iptables for the Istio proxy, you cannot run Istio (and therefore Solo Enterprise for Istio) on AWS Fargate. For more information, see the Amazon EKS issue.

Single cluster

Upgrade istioctl

  1. Save the details for the version of the Solo distribution of Istio that you want to upgrade to.

    1. Save the Solo distribution of Istio patch version and tag.
      export ISTIO_VERSION=1.26.8-patch7
      # Change the tags as needed
      export ISTIO_IMAGE=${ISTIO_VERSION}-solo
    2. Save the repo key for the minor version of the Solo distribution of Istio that you want to install. This is the 12-character hash at the end of the repo URL us-docker.pkg.dev/gloo-mesh/istio-<repo-key>, which you can find in the Istio images built by Solo.io support article.
      # 12-character hash at the end of the minor version repo URL
      export REPO_KEY=<repo_key>
      export REPO=us-docker.pkg.dev/gloo-mesh/istio-${REPO_KEY}
      export HELM_REPO=us-docker.pkg.dev/gloo-mesh/istio-helm-${REPO_KEY}
  2. Upgrade your istioctl CLI client to the new version.

    curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} sh -
    cd istio-${ISTIO_VERSION}
    export PATH=$PWD/bin:$PATH

Upgrade CRDs and istiod

  1. Upgrade the custom resources of the Kubernetes Gateway API to the latest supported version, 1.2.1.

    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml
  2. Upgrade the Istio CRDs to the new version.

    helm get values istio-base -n istio-system -o yaml > istio-base.yaml
    helm upgrade istio-base oci://${HELM_REPO}/base \
    --namespace istio-system \
    --version ${ISTIO_IMAGE} \
    -f istio-base.yaml

    Note

    If you see an error such as Error: UPGRADE FAILED: Rendered manifests contain a resource that already exists, see the community Istio docs.

  3. Get the current values for the istiod Helm release in your cluster.

    helm get values istiod -n istio-system -o yaml > istiod.yaml
    open istiod.yaml
  4. Make edits to the istiod Helm values, and save the file. If you update the Istio minor version, such as in the global.tag field, be sure to also update the value of the hub field to the repo for the correct version of the Solo distribution of Istio.

  5. Upgrade your Helm release with the updated values.

    helm upgrade istiod oci://${HELM_REPO}/istiod \
    -n istio-system \
    --version ${ISTIO_IMAGE} \
    -f istiod.yaml
  6. Verify that the istiod pods are successfully restarted. Note that it might take a few seconds for the pods to become available.

    kubectl get pods -n istio-system | grep istiod

    Example output:

    istiod-b84c55cff-tllfr   1/1     Running   0          58s

Upgrade the CNI and ztunnel

Note

If your changes include upgrading the Istio version of the components, be sure to upgrade the istiod control plane before you upgrade the CNI and ztunnel components. Otherwise, these components might have an outdated image.

  1. For the component that you want to update, get the current values for its Helm release in your cluster.

    helm get values istio-cni -n istio-system -o yaml > cni.yaml
    open cni.yaml
    helm get values ztunnel -n istio-system -o yaml > ztunnel.yaml
    open ztunnel.yaml
  2. Make edits to the Helm values of the components that you want to upgrade, and save the files. If you update the Istio minor version, such as in tag fields, be sure to also update the value of the hub field to the repo for the correct version of the Solo distribution of Istio.

  3. Upgrade your Helm releases with the updated values.

    helm upgrade istio-cni oci://${HELM_REPO}/cni -n istio-system --version ${ISTIO_IMAGE} -f cni.yaml
    helm upgrade ztunnel oci://${HELM_REPO}/ztunnel -n istio-system --version ${ISTIO_IMAGE} -f ztunnel.yaml
  4. Verify that the ztunnel and Istio CNI pods are successfully restarted. Note that it might take a few seconds for the pods to become available.

    kubectl get pods -n istio-system

    Example output:

    istiod-85c4dfd97f-mncj5            1/1     Running   0             42s
    istio-cni-node-pr5rl               1/1     Running   0             42s
    istio-cni-node-pvmx2               1/1     Running   0             42s
    istio-cni-node-lcrcd               1/1     Running   0             42s
    ztunnel-tvtzn                      1/1     Running   0             40s
    ztunnel-vtpjm                      1/1     Running   0             40s
    ztunnel-hllxg                      1/1     Running   0             40s

Multicluster

Upgrade the multicluster ambient mesh in your multicluster setup.

Upgrade istioctl

  1. Set environment variables for the Solo distribution of Istio that you want to upgrade to. You can find these values in the Istio images built by Solo.io support article.

    # Solo distribution of Istio patch version
    # in the format 1.x.x, with no tags
    export ISTIO_VERSION=<istio_version>
    # Repo key for the minor version of the Solo distribution of Istio
    # This is the 12-character hash at the end of the repo URL: 'us-docker.pkg.dev/gloo-mesh/istio-<repo-key>'
    export REPO_KEY=<repo_key>
    export HELM_REPO=us-docker.pkg.dev/gloo-mesh/istio-helm-${REPO_KEY}
    export ISTIO_IMAGE=${ISTIO_VERSION}-solo
    export REPO=us-docker.pkg.dev/gloo-mesh/istio-${REPO_KEY}
  2. Upgrade your istioctl CLI client to the new version. This script automatically detects your OS and architecture, downloads the appropriate Solo distribution of Istio binary, and verifies the installation.

    bash <(curl -sSfL https://raw.githubusercontent.com/solo-io/doc-examples/main/istio/install-istioctl.sh)
    export PATH=${HOME}/.istioctl/bin:${PATH}

Upgrade CRDs and istiod

  1. Save the kubeconfig context of a cluster where you want to upgrade Istio in an environment variable. Each time you repeat the steps in this guide, you change this variables to the next cluster’s context.

    export ctx=<cluster-context>
  2. Upgrade the custom resources of the Kubernetes Gateway API to the latest supported version, 1.2.1.

    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml --context ${ctx}
  3. Upgrade the Istio CRDs to the new version.

    helm get values --kube-context ${ctx} istio-base -n istio-system -o yaml > istio-base.yaml
    helm upgrade istio-base oci://${HELM_REPO}/base \
    --namespace istio-system \
    --kube-context ${ctx} \
    --version ${ISTIO_IMAGE} \
    -f istio-base.yaml

    Note

    If you see an error such as Error: UPGRADE FAILED: Rendered manifests contain a resource that already exists, see the community Istio docs.

  4. Get the current values for the istiod Helm release in your cluster.

    helm get values --kube-context ${ctx} istiod -n istio-system -o yaml > istiod.yaml
    open istiod.yaml
  5. Make edits to the istiod Helm values, and save the file. If you update the Istio minor version, such as in the global.tag field, be sure to also update the value of the hub field to the repo for the correct version of the Solo distribution of Istio.

  6. Upgrade your Helm release with the updated values.

    helm upgrade istiod oci://${HELM_REPO}/istiod \
    -n istio-system \
    --version ${ISTIO_IMAGE} \
    --kube-context ${ctx} \
    -f istiod.yaml
  7. Verify that the istiod pods are successfully restarted. Note that it might take a few seconds for the pods to become available.

    kubectl get pods --context ${ctx} -n istio-system | grep istiod

    Example output:

    istiod-b84c55cff-tllfr   1/1     Running   0          58s

Upgrade the CNI and ztunnel

Note

If your changes include upgrading the Istio version of the components, be sure to upgrade the istiod control plane before you upgrade the CNI and ztunnel components. Otherwise, these components might have an outdated image.

  1. For the component that you want to update, get the current values for its Helm release in your cluster.

    helm get values istio-cni --kube-context ${ctx} -n istio-system -o yaml > cni.yaml
    open cni.yaml
    
    helm get values ztunnel --kube-context ${ctx} -n istio-system -o yaml > ztunnel.yaml
    open ztunnel.yaml
  2. Make edits to the Helm values of the components that you want to upgrade, and save the files. If you update the Istio minor version, such as in tag fields, be sure to also update the value of the hub field to the repo for the correct version of the Solo distribution of Istio.

  3. Upgrade your Helm releases with the updated values.

    helm upgrade istio-cni oci://${HELM_REPO}/cni --kube-context ${ctx} -n istio-system --version ${ISTIO_IMAGE} -f cni.yaml
    
    helm upgrade ztunnel oci://${HELM_REPO}/ztunnel --kube-context ${ctx} -n istio-system --version ${ISTIO_IMAGE} -f ztunnel.yaml
  4. Verify that the ztunnel and Istio CNI pods are successfully restarted. Note that it might take a few seconds for the pods to become available.

    kubectl get pods --context ${ctx} -n istio-system

    Example output:

    istiod-85c4dfd97f-mncj5            1/1     Running   0             42s
    istio-cni-node-pr5rl               1/1     Running   0             42s
    istio-cni-node-pvmx2               1/1     Running   0             42s
    istio-cni-node-lcrcd               1/1     Running   0             42s
    ztunnel-tvtzn                      1/1     Running   0             40s
    ztunnel-vtpjm                      1/1     Running   0             40s
    ztunnel-hllxg                      1/1     Running   0             40s

Repeat for each cluster

Repeat Upgrade CRDs and istiod and Upgrade the CNI and ztunnel for each cluster in your setup. Note that no multicluster components, such as the east-west gateway or global service entries, require upgrades when you update the version of your other control and data plane components.