Merge pull request #278325 from german1608/patch-2

Update istio-upgrade.md

Author: prmerger-automator[bot]

articles/aks/istio-upgrade.md

@@ -6,6 +6,7 @@ ms.service: azure-kubernetes-service
 ms.date: 05/04/2023
 ms.author: shasb
 author: shashankbarsin
+ms.custom: devx-track-azurecli
 ---
 
 # Upgrade Istio-based service mesh add-on for Azure Kubernetes Service
@@ -20,27 +21,27 @@ Istio add-on allows upgrading the minor revision using [canary upgrade process][
 
 If the cluster is currently using a supported minor revision of Istio, upgrades are only allowed one minor revision at a time. If the cluster is using an unsupported revision of Istio, you must upgrade to the lowest supported minor revision of Istio for that Kubernetes version. After that, upgrades can again be done one minor revision at a time.
 
-The following example illustrates how to upgrade from revision `asm-1-18` to `asm-1-19`. The steps are the same for all minor upgrades.
+The following example illustrates how to upgrade from revision `asm-1-20` to `asm-1-21`. The steps are the same for all minor upgrades.
 
 1. Use the [az aks mesh get-upgrades](/cli/azure/aks/mesh#az-aks-mesh-get-upgrades) command to check which revisions are available for the cluster as upgrade targets:
 
-    ```bash
+    ```azurecli-interactive
     az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER
     ```
 
     If you expect to see a newer revision not returned by this command, you may need to upgrade your AKS cluster first so that it's compatible with the newest revision.
 
 1. If you've set up [mesh configuration][meshconfig] for the existing mesh revision on your cluster, you need to create a separate ConfigMap corresponding to the new revision in the `aks-istio-system` namespace **before initiating the canary upgrade** in the next step. This configuration is applicable the moment the new revision's control plane is deployed on cluster. More details can be found [here][meshconfig-canary-upgrade].
 
-1. Initiate a canary upgrade from revision `asm-1-18` to `asm-1-19` using [az aks mesh upgrade start](/cli/azure/aks/mesh#az-aks-mesh-upgrade-start):
+1. Initiate a canary upgrade from revision `asm-1-20` to `asm-1-21` using [az aks mesh upgrade start](/cli/azure/aks/mesh/upgrade#az-aks-mesh-upgrade-start):
 
-    ```bash
-    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-19
+    ```azurecli-interactive
+    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-21
     ```
 
-    A canary upgrade means the 1.18 control plane is deployed alongside the 1.17 control plane. They continue to coexist until you either complete or roll back the upgrade.
+    A canary upgrade means the 1.20 control plane is deployed alongside the 1.21 control plane. They continue to coexist until you either complete or roll back the upgrade.
 
-1. Verify control plane pods corresponding to both `asm-1-18` and `asm-1-19` exist:
+1. Verify control plane pods corresponding to both `asm-1-20` and `asm-1-21` exist:
 
     * Verify `istiod` pods:
 
@@ -52,10 +53,10 @@ The following example illustrates how to upgrade from revision `asm-1-18` to `as
 
         ```
         NAME                                        READY   STATUS    RESTARTS   AGE
-        istiod-asm-1-18-55fccf84c8-dbzlt            1/1     Running   0          58m
-        istiod-asm-1-18-55fccf84c8-fg8zh            1/1     Running   0          58m
-        istiod-asm-1-19-f85f46bf5-7rwg4             1/1     Running   0          51m
-        istiod-asm-1-19-f85f46bf5-8p9qx             1/1     Running   0          51m
+        istiod-asm-1-20-55fccf84c8-dbzlt            1/1     Running   0          58m
+        istiod-asm-1-20-55fccf84c8-fg8zh            1/1     Running   0          58m
+        istiod-asm-1-21-f85f46bf5-7rwg4             1/1     Running   0          51m
+        istiod-asm-1-21-f85f46bf5-8p9qx             1/1     Running   0          51m
         ```
 
     * If ingress is enabled, verify ingress pods:
@@ -68,22 +69,22 @@ The following example illustrates how to upgrade from revision `asm-1-18` to `as
 
         ```
         NAME                                                          READY   STATUS    RESTARTS   AGE
-        aks-istio-ingressgateway-external-asm-1-18-58f889f99d-qkvq2   1/1     Running   0          59m
-        aks-istio-ingressgateway-external-asm-1-18-58f889f99d-vhtd5   1/1     Running   0          58m
-        aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-ft9c8   1/1     Running   0          51m
-        aks-istio-ingressgateway-external-asm-1-19-7466f77bb9-wcb6s   1/1     Running   0          51m
-        aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-4cc2l   1/1     Running   0          58m
-        aks-istio-ingressgateway-internal-asm-1-18-579c5d8d4b-jjc7m   1/1     Running   0          59m
-        aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-g89s4   1/1     Running   0          51m
-        aks-istio-ingressgateway-internal-asm-1-19-757d9b5545-krq9w   1/1     Running   0          51m
+        aks-istio-ingressgateway-external-asm-1-20-58f889f99d-qkvq2   1/1     Running   0          59m
+        aks-istio-ingressgateway-external-asm-1-20-58f889f99d-vhtd5   1/1     Running   0          58m
+        aks-istio-ingressgateway-external-asm-1-21-7466f77bb9-ft9c8   1/1     Running   0          51m
+        aks-istio-ingressgateway-external-asm-1-21-7466f77bb9-wcb6s   1/1     Running   0          51m
+        aks-istio-ingressgateway-internal-asm-1-20-579c5d8d4b-4cc2l   1/1     Running   0          58m
+        aks-istio-ingressgateway-internal-asm-1-20-579c5d8d4b-jjc7m   1/1     Running   0          59m
+        aks-istio-ingressgateway-internal-asm-1-21-757d9b5545-g89s4   1/1     Running   0          51m
+        aks-istio-ingressgateway-internal-asm-1-21-757d9b5545-krq9w   1/1     Running   0          51m
         ```
 
         Observe that ingress gateway pods of both revisions are deployed side-by-side. However, the service and its IP remain immutable.
 
 1. Relabel the namespace so that any new pods get the Istio sidecar associated with the new revision and its control plane:
 
     ```bash
-    kubectl label namespace default istio.io/rev=asm-1-19 --overwrite
+    kubectl label namespace default istio.io/rev=asm-1-21 --overwrite
     ```
 
     Relabeling doesn't affect your workloads until they're restarted.
@@ -98,7 +99,7 @@ The following example illustrates how to upgrade from revision `asm-1-18` to `as
 
     * **Complete the canary upgrade**: If you're satisfied that the workloads are all running in a healthy state as expected, you can complete the canary upgrade. Completion of the upgrade removes the previous revision's control plane and leaves behind the new revision's control plane on the cluster. Run the following command to complete the canary upgrade:
 
-      ```bash
+      ```azurecli-interactive
       az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER
       ```
 
@@ -107,7 +108,7 @@ The following example illustrates how to upgrade from revision `asm-1-18` to `as
       * Relabel the namespace to the previous revision:
 
           ```bash
-          kubectl label namespace default istio.io/rev=asm-1-18 --overwrite
+          kubectl label namespace default istio.io/rev=asm-1-20 --overwrite
           ```
 
       * Roll back the workloads to use the sidecar corresponding to the previous Istio revision by restarting these workloads again:
@@ -118,7 +119,7 @@ The following example illustrates how to upgrade from revision `asm-1-18` to `as
 
       * Roll back the control plane to the previous revision:
 
-          ```
+          ```azurecli-interactive
           az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER
           ```
 
@@ -147,8 +148,8 @@ Thus, during the canary upgrade, when two revisions exist simultaneously on the
     Example output:
 
     ```bash
-    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless",
-    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless"
+    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distroless",
+    "image": "mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distroless"
     ```
 
   * Check the Istio proxy image version for all pods in a namespace:
@@ -162,7 +163,7 @@ Thus, during the canary upgrade, when two revisions exist simultaneously on the
     Example output:
 
     ```bash
-    productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.1-distroless
+    productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.20.0, mcr.microsoft.com/oss/istio/proxyv2:1.20.6-distroless
     ```
 
   * To trigger reinjection, restart the workloads. For example:
@@ -182,11 +183,15 @@ Thus, during the canary upgrade, when two revisions exist simultaneously on the
     Example output:
 
     ```bash
-    productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.18.0, mcr.microsoft.com/oss/istio/proxyv2:1.18.2-distroless
+    productpage-v1-979d4d9fc-p4764:	docker.io/istio/examples-bookinfo-productpage-v1:1.20.0, mcr.microsoft.com/oss/istio/proxyv2:1.20.7-distroless
     ```
 
+> [!NOTE]
+> In case of any issues encountered during upgrades, refer to [article on troubleshooting mesh revision upgrades][upgrade-istio-service-mesh-tsg]
+
 [aks-release-notes]: https://github.com/Azure/AKS/releases
 [istio-canary-upstream]: https://istio.io/latest/docs/setup/upgrade/canary/
 [meshconfig]: ./istio-meshconfig.md
 [meshconfig-canary-upgrade]: ./istio-meshconfig.md#mesh-configuration-and-upgrades
+[upgrade-istio-service-mesh-tsg]: /troubleshoot/azure/azure-kubernetes/extensions/istio-add-on-minor-revision-upgrade