本文介绍适用于 Azure Kubernetes 服务的基于 Istio 的服务网格加载项的升级体验 (AKS)。
有关基于 Istio 的服务网格加载项的新次要修订或补丁发布的公告已在 AKS 发行说明中发布。 若要详细了解服务网格加载项修订的发布计划和支持，请阅读支持策略。
Istio 加载项允许使用 Canary 升级过程升级次要修订。 启动升级时，新 (Canary) 修订的控制平面将与初始（稳定）修订的控制平面一起部署。 然后，可以手动滚动数据平面工作负载，同时使用监视工具在此过程中跟踪工作负载的健康状况。 如果没有发现工作负载健康状况出现任何问题，则可以完成升级，以便群集上仅保留新版本。 否则，可以回滚到 Istio 的上一版本。
如果群集当前使用受支持的 Istio 次要修订，则一次只允许升级一个次要修订。 如果群集使用的是不受支持的 Istio 修订，则必须升级到该 Kubernetes 修订支持的最低 Istio 次要修订。 之后，可以再次一次升级一个次要修订。
下面的示例说明了如何将 default 命名空间中的所有工作负载从修订版 asm-1-22 升级到修订版 asm-1-23。 所有次要升级的步骤都是相同的，可用于任意数量的命名空间。
使用 az aks mesh get-upgrades 命令检查哪些版本可作为群集的升级目标：
az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER如果希望看到此命令不返回较新版本，则可能需要先升级 AKS 群集，使其与最新版本兼容。
如果为群集上的现有网格修订设置了网格配置，则需要在下一步启动 Canary 升级之前，在
aks-istio-system命名空间中创建与新修订对应的单独 ConfigMap。 在群集上部署新版本的控制平面时，此配置适用。 此处提供了更多详细信息。使用 az aks mesh upgrade start 启动从版本
asm-1-22到asm-1-23的 Canary 升级：az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-23Canary 升级意味着将 1.23 控制平面与 1.22 控制平面一起部署。 它们将继续共存，直到你完成或回滚升级。
（可选）修订标记可用于将数据平面滚动更新到新修订，而无需手动重新标记每个命名空间。 将命名空间移动到新版本时手动重新标记命名空间可能很繁琐且容易出错。 修订标记通过充当指向修订的稳定标识符来解决此问题。
集群操作员可以更改标签使其指向新的修订版，而不是重新标记每个命名空间。 所有标有该标记的命名空间会同时更新。 但是，你仍然需要重启工作负载，以确保注入正确版本的
istio-proxysidecar。若要在升级期间使用修订标记，请执行以下操作：
为初始修订版创建修订标记。 在此示例中，我们将它命名为
prod-stable：istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system为升级期间安装的修订版创建修订标记。 在此示例中，我们将它命名为
prod-canary：istioctl tag set prod-canary --revision asm-1-23 --istioNamespace aks-istio-system标记应用程序命名空间，以便映射到修订标记：
# label default namespace to map to asm-1-22 kubectl label ns default istio.io/rev=prod-stable --overwrite还可以将命名空间标注为
istio.io/rev=prod-canary，用于较新版本。 但是，这些命名空间中的工作负荷在重新启动之前不会更新为新的 sidecar。如果在标记命名空间后在命名空间中创建一个新应用程序，则会在该命名空间上注入对应于修订标记的 sidecar。
验证与
asm-1-22和asm-1-23对应的控制平面 Pod 是否存在：验证
istiodPod：kubectl get pods -n aks-istio-system示例输出：
NAME READY STATUS RESTARTS AGE istiod-asm-1-22-55fccf84c8-dbzlt 1/1 Running 0 58m istiod-asm-1-22-55fccf84c8-fg8zh 1/1 Running 0 58m istiod-asm-1-23-f85f46bf5-7rwg4 1/1 Running 0 51m istiod-asm-1-23-f85f46bf5-8p9qx 1/1 Running 0 51m如果启用了入口，请验证入口 Pod：
kubectl get pods -n aks-istio-ingress示例输出：
NAME READY STATUS RESTARTS AGE aks-istio-ingressgateway-external-asm-1-22-58f889f99d-qkvq2 1/1 Running 0 59m aks-istio-ingressgateway-external-asm-1-22-58f889f99d-vhtd5 1/1 Running 0 58m aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-ft9c8 1/1 Running 0 51m aks-istio-ingressgateway-external-asm-1-23-7466f77bb9-wcb6s 1/1 Running 0 51m aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-4cc2l 1/1 Running 0 58m aks-istio-ingressgateway-internal-asm-1-22-579c5d8d4b-jjc7m 1/1 Running 0 59m aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-g89s4 1/1 Running 0 51m aks-istio-ingressgateway-internal-asm-1-23-757d9b5545-krq9w 1/1 Running 0 51m观察两个版本的入口网关 Pod 是否并行部署。 但是，服务及其 IP 保持不可变。
重新命名命名空间，以便将任何新 Pod 映射到与新版本及其控制平面相关联的 Istio sidecar：
如果使用修订标记，请覆盖
prod-stable标记本身以更改其映射：istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite验证标记到修订映射：
istioctl tag list这两个标记应指向新安装的修订版：
TAG REVISION NAMESPACES prod-canary asm-1-23 default prod-stable asm-1-23 ...在这种情况下，无需单独重新标记每个命名空间。
如果未使用修订标记，则必须重新标记数据平面命名空间，以指向新修订版：
kubectl label namespace default istio.io/rev=asm-1-23 --overwrite
重新标记不会影响工作负载，直到工作负载重新启动。
通过重新启动每个应用程序工作负载来单独滚动。 例如：
kubectl rollout restart deployment <deployment name> -n <deployment namespace>检查监视工具和仪表板，以确定工作负载在重启后是否都以健康状态运行。 根据结果，有两个选项：
完成 Canary 升级：如果确信工作负载都按以健康状态运行，则可以完成 Canary 升级。 升级完成后会删除上一修订的控制平面，并将新修订的控制平面保留在群集上。 运行以下命令以完成 Canary 升级：
az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER回滚 Canary 升级：如果发现工作负载健康状况出现任何问题，可以回滚到 Istio 的上一个版本：
将命名空间重新标记到上一个修订版：如果使用修订标记：
istioctl tag set prod-stable --revision asm-1-22 --istioNamespace aks-istio-system --overwrite或者，如果不使用修订标记：
kubectl label namespace default istio.io/rev=asm-1-22 --overwrite通过再次重启这些工作负载，回滚工作负载以使用与 Istio 上一版本对应的挎斗：
kubectl rollout restart deployment <deployment name> -n <deployment namespace>将控制平面回滚到上一版本：
az aks mesh upgrade rollback --resource-group $RESOURCE_GROUP --name $CLUSTER
可以移除
prod-canary修订标记：istioctl tag remove prod-canary --istioNamespace aks-istio-system如果之前为修订版设置了网格配置，现在可以删除在完成/回滚时从群集中移除的修订版的 ConfigMap。
如果你当前正在使用 Istio 入口网关并且正在执行次要修订升级，请记住，Istio 入口网关 Pod/部署是按修订部署的。 但是，我们在多个修订中跨所有入口网关 Pod 提供单一 LoadBalancer 服务，因此入口网关的外部/内部 IP 地址在整个升级过程中保持不变。
因此，在 Canary 升级期间，当群集上同时存在两个修订时，这两个修订的入口网关 Pod 为传入流量提供服务。
如果已为 Istiod 或入口网关自定义水平 Pod 自动缩放 (HPA) 设置，请注意以下行为，以了解如何在两个修订中应用 HPA 设置，从而在 Canary 升级期间保持一致性：
- 如果在启动升级之前更新 HPA 规范，则安装新的控制平面时，现有（稳定）修订的设置将应用于 Canary 修订的 HPA。
- 如果在 Canary 升级正在进行时更新 HPA 规范，则稳定修订的 HPA 规范将优先，并应用于 Canary 修订的 HPA。
- 如果在升级期间更新稳定修订的 HPA，则将更新 Canary 修订的 HPA 规范以反映应用于稳定修订的新设置。
- 如果在升级期间更新 Canary 修订的 HPA，则 Canary 修订的 HPA 规格将还原为稳定修订的 HPA 规范。
- Istio 加载项补丁版本可用性信息在 AKS 发行说明中发布。
- 作为这些 AKS 版本的一部分，会自动推出适用于 istiod 和入口 Pod 的补丁，将遵循为群集设置的
default计划内维护时段。 - 用户需要在其工作负载中启动 Istio 代理的补丁，方法是重启 Pod 以便重新注入：
检查适用于新 Pod 或重启后的 Pod 的 Istio 代理的版本。 修补 istiod 和 Istio 入口 Pod 后，此版本与它们的版本相同：
kubectl get cm -n aks-istio-system -o yaml | grep "mcr.azk8s.cn\/oss\/istio\/proxyv2"示例输出：
"image": "mcr.azk8s.cn/oss/istio/proxyv2:1.22.0-distroless", "image": "mcr.azk8s.cn/oss/istio/proxyv2:1.22.0-distroless"检查命名空间中所有 Pod 的 Istio 代理映像版本：
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort |\ grep "mcr.azk8s.cn\/oss\/istio\/proxyv2"示例输出：
productpage-v1-979d4d9fc-p4764: docker.io/istio/examples-bookinfo-productpage-v1:1.22.0, mcr.azk8s.cn/oss/istio/proxyv2:1.22.0-distroless若要触发重新注入，请重启工作负载。 例如：
kubectl rollout restart deployments/productpage-v1 -n default若要验证它们现在是否使用较新版本，请再次为命名空间中的所有 Pod 检查 Istio 代理映像版本：
kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ sort |\ grep "mcr.azk8s.cn\/oss\/istio\/proxyv2"示例输出：
productpage-v1-979d4d9fc-p4764: docker.io/istio/examples-bookinfo-productpage-v1:1.2.0, mcr.azk8s.cn/oss/istio/proxyv2:1.22.0-distroless
备注
如果在升级过程中遇到任何问题，请参阅有关排除网格修订升级故障的文章