Considerations

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

Revision and canary upgrade limitations

Revisioned upgrades are supported only for the istiod control plane and Istio gateways in ambient installations. Due to an upstream ambient limitation, the ztunnel and Istio CNI pods do not support revisioned canary upgrades, and can only be upgraded in-place. For this reason, creating named revisions for the istiod, cni, ztunnel, and gateways in an ambient mesh is not currently recommended.

CNI upgrades

When you use the Solo distribution of Istio, 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. When istio-cni detects that the removal is due to an upgrade, it 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.

Upgrade CRDs

Upgrade your ambient control plane and data plane components by editing the appropriate Helm releases.

  1. Save the version that you want to upgrade to in the following environment variables, such as the following examples for 1.24. You can find these values in the Ambient section of the Istio images built by Solo.io support article.

      # Solo distrubution of Istio patch version and tag, in the format 1.x.x-solo
    export ISTIO_IMAGE=1.24.2-solo
    # Solo distrubution of Istio repo
    export REPO=us-docker.pkg.dev/gloo-mesh/istio-<repo-key>
    # Solo distrubution of Istio Helm repo
    export HELM_REPO=us-docker.pkg.dev/gloo-mesh/istio-helm-<repo-key>
      
  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 \
    --create-namespace \
    --version ${ISTIO_IMAGE} \
    -f istio-base.yaml
      

Upgrade istiod

  1. 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
      
  2. 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.

  3. Upgrade your Helm release with the updated values.

      helm upgrade istiod oci://${HELM_REPO}/istiod -n istio-system --version ${ISTIO_IMAGE} -f istiod.yaml
      
  4. 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, ztunnel, and gateways

  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 kube-system -o yaml > cni.yaml
    open cni.yaml
      
      helm get values ztunnel -n istio-system -o yaml > ztunnel.yaml
    open ztunnel.yaml
      
      helm get values istio-ingressgateway -n gloo-mesh-gateways -o yaml > ingress.yaml
    open ingress.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 kube-system --version ${ISTIO_IMAGE} -f cni.yaml
      
      helm upgrade ztunnel oci://${HELM_REPO}/ztunnel -n istio-system --version ${ISTIO_IMAGE} -f ztunnel.yaml
      
      helm upgrade istio-ingressgateway oci://${HELM_REPO}/gateway -n gloo-mesh-gateways --version ${ISTIO_IMAGE} -f ingress.yaml
      
  4. Verify that the ztunnel, Istio CNI, or gateway pods are successfully restarted. Note that it might take a few seconds for the pods to become available.

      kubectl get pods -A | grep istio
      

    Example output:

      gloo-mesh-gateways   istio-ingressgateway-65c5874ffd-jp78c               1/1     Running   0             39s
    istio-system         istiod-85c4dfd97f-mncj5                             1/1     Running   0             42s
    istio-system         ztunnel-tvtzn                                       1/1     Running   0             40s
    istio-system         ztunnel-vtpjm                                       1/1     Running   0             40s
    istio-system         ztunnel-hllxg                                       1/1     Running   0             40s
    kube-system          istio-cni-node-pr5rl                                1/1     Running   0             42s
    kube-system          istio-cni-node-pvmx2                                1/1     Running   0             42s
    kube-system          istio-cni-node-lcrcd                                1/1     Running   0             42s