通过

升级适用于 Azure Kubernetes 服务的基于 Istio 的服务网格加载项

  • 项目

本文介绍适用于 Azure Kubernetes 服务的基于 Istio 的服务网格加载项的升级体验 (AKS)。

有关基于 Istio 的服务网格加载项的新次要修订或补丁发布的公告已在 AKS 发行说明中发布。 若要详细了解服务网格加载项修订的发布计划和支持，请阅读支持策略。

次要修订升级

Istio 加载项允许使用 Canary 升级过程升级次要修订。 启动升级时，新 (Canary) 修订的控制平面将与初始（稳定）修订的控制平面一起部署。 然后，可以手动滚动数据平面工作负载，同时使用监视工具在此过程中跟踪工作负载的健康状况。 如果没有发现工作负载健康状况出现任何问题，则可以完成升级，以便群集上仅保留新版本。 否则，可以回滚到 Istio 的上一版本。

可用升级取决于当前 Istio 修订版和 AKS 群集版本是否受支持：

  • 可以升级到下一个受支持的修订版 (n+1) 或跳过一个版本并升级到 n+2，只要两者都受支持且与群集版本兼容即可。
  • 如果当前修订版 (n) 和下一个修订版 (n+1) 都不受支持，则只能升级到最近的受支持修订版（n+2 或更高版本），但不能超越该版本。
  • 如果群集版本和 Istio 修订版都不受支持，则必须升级群集版本，然后才能启动 Istio 升级。

注意

一旦 AKS 版本或网格修订版超出支持时限，升级任一版本都会容易出错。 虽然此类升级允许恢复到受支持的版本，但升级过程和超出支持范围的版本本身均不享受 Microsoft 的支持。 我们强烈建议使 AKS 版本和网格修订版保持最新，以避免遇到版本不受支持的情况。 请参阅 Istio 加载项支持日历来了解估计的发布和生命周期结束日期，并参阅上游 Istio 发行说明来了解新版本的显著变化。

下面的示例说明了如何将 asm-1-23 命名空间中的所有工作负载从修订版 asm-1-24 升级到修订版 default。 所有次要升级的步骤都是相同的，可用于任意数量的命名空间。

  1. 使用 az aks mesh get-upgrades 命令检查哪些版本可作为群集的升级目标：

    az aks mesh get-upgrades --resource-group $RESOURCE_GROUP --name $CLUSTER

    如果希望看到此命令不返回较新版本，则可能需要先升级 AKS 群集，使其与最新版本兼容。

  2. 如果为群集上的现有网格修订设置了网格配置，则需要在下一步启动 Canary 升级之前，在 aks-istio-system 命名空间中创建与新修订对应的单独 ConfigMap。 在群集上部署新版本的控制平面时，此配置适用。 此处提供了更多详细信息。

  3. 使用 asm-1-23 启动从版本 asm-1-24 到 的 Canary 升级：

    az aks mesh upgrade start --resource-group $RESOURCE_GROUP --name $CLUSTER --revision asm-1-24

    Canary 升级是指将 1.24 控制平面与 1.23 控制平面并行部署的升级方式。 它们将继续共存，直到你完成或回滚升级。

    在 Canary 升级过程中，较高的修订版本被视为用于验证 Istio 资源的默认修订版。

  4. （可选）修订标记可用于将数据平面滚动更新到新修订，而无需手动重新标记每个命名空间。 将命名空间移动到新版本时手动重新标记命名空间可能很繁琐且容易出错。 修订标记通过充当指向修订的稳定标识符来解决此问题。

    集群操作员可以更改标签使其指向新的修订版，而不是重新标记每个命名空间。 所有标有该标记的命名空间会同时更新。 但是，你仍然需要重启工作负载，以确保注入正确版本的 istio-proxy sidecar。

    若要在升级期间使用修订标记，请执行以下操作：

    1. 安装 istioctl CLI

    2. 为初始修订版创建修订标记。 在此示例中，我们将它命名为 prod-stable：

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system

    3. 为升级期间安装的修订版创建修订标记。 在此示例中，我们将它命名为 prod-canary：

      istioctl tag set prod-canary --revision asm-1-24 --istioNamespace aks-istio-system

    4. 标记应用程序命名空间，以便映射到修订标记：

      # label default namespace to map to asm-1-23
kubectl label ns default istio.io/rev=prod-stable --overwrite

      还可以将命名空间标注为 istio.io/rev=prod-canary，用于较新版本。 但是，这些命名空间中的工作负荷在重新启动之前不会更新为新的 sidecar。

      如果在标记命名空间后在命名空间中创建一个新应用程序，则会在该命名空间上注入对应于修订标记的 sidecar。

  5. 验证与 asm-1-23 和 asm-1-24 对应的控制平面 Pod 是否存在：

    1. 验证 istiod Pod：

      kubectl get pods -n aks-istio-system

      示例输出：

      NAME                                        READY   STATUS    RESTARTS   AGE
istiod-asm-1-23-55fccf84c8-dbzlt            1/1     Running   0          58m
istiod-asm-1-23-55fccf84c8-fg8zh            1/1     Running   0          58m
istiod-asm-1-24-f85f46bf5-7rwg4             1/1     Running   0          51m
istiod-asm-1-24-f85f46bf5-8p9qx             1/1     Running   0          51m

    2. 如果启用了入口，请验证入口 Pod：

      kubectl get pods -n aks-istio-ingress

      示例输出：

      NAME                                                          READY   STATUS    RESTARTS   AGE
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-qkvq2   1/1     Running   0          59m
aks-istio-ingressgateway-external-asm-1-23-58f889f99d-vhtd5   1/1     Running   0          58m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-ft9c8   1/1     Running   0          51m
aks-istio-ingressgateway-external-asm-1-24-7466f77bb9-wcb6s   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-4cc2l   1/1     Running   0          58m
aks-istio-ingressgateway-internal-asm-1-23-579c5d8d4b-jjc7m   1/1     Running   0          59m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-g89s4   1/1     Running   0          51m
aks-istio-ingressgateway-internal-asm-1-24-757d9b5545-krq9w   1/1     Running   0          51m

      观察两个版本的入口网关 Pod 是否并行部署。 但是，服务及其 IP 保持不可变。

  6. 重新命名命名空间，以便将任何新 Pod 映射到与新版本及其控制平面相关联的 Istio sidecar：

    1. 如果使用修订标记，请覆盖 prod-stable 标记本身以更改其映射：

      istioctl tag set prod-stable --revision asm-1-24 --istioNamespace aks-istio-system --overwrite

      验证标记到修订映射：

      istioctl tag list

      这两个标记应指向新安装的修订版：

      TAG           REVISION   NAMESPACES
prod-canary   asm-1-24   default
prod-stable   asm-1-24   ...

      在这种情况下，无需单独重新标记每个命名空间。

    2. 如果未使用修订标记，则必须重新标记数据平面命名空间，以指向新修订版：

      kubectl label namespace default istio.io/rev=asm-1-24 --overwrite

    重新标记不会影响工作负载，直到工作负载重新启动。

  7. 通过重新启动每个应用程序工作负载来单独滚动。 例如：

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>

  8. 检查监视工具和仪表板，以确定工作负载在重启后是否都以健康状态运行。 根据结果，有两个选项：

    1. 完成 Canary 升级：如果确信工作负载都按以健康状态运行，则可以完成 Canary 升级。 升级完成后会删除上一修订的控制平面，并将新修订的控制平面保留在群集上。 运行以下命令以完成 Canary 升级：

      az aks mesh upgrade complete --resource-group $RESOURCE_GROUP --name $CLUSTER

    2. 回滚 Canary 升级：如果发现工作负载健康状况出现任何问题，可以回滚到 Istio 的上一个版本：

    • 将命名空间重新标记到上一个修订版：如果使用修订标记：

      istioctl tag set prod-stable --revision asm-1-23 --istioNamespace aks-istio-system --overwrite

      或者，如果不使用修订标记：

      kubectl label namespace default istio.io/rev=asm-1-23 --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

  9. 如果之前为修订版设置了网格配置，现在可以删除在完成/回滚时从群集中移除的修订版的 ConfigMap。

使用入口网关进行次要修订升级

如果你当前正在使用 Istio 入口网关并且正在执行次要修订升级，请记住，Istio 入口网关 Pod/部署是按修订部署的。 但是，我们在多个修订中跨所有入口网关 Pod 提供单一 LoadBalancer 服务，因此入口网关的外部/内部 IP 地址在整个升级过程中保持不变。

因此，在 Canary 升级期间，当群集上同时存在两个修订时，这两个修订的入口网关 Pod 为传入流量提供服务。

使用水平 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.23.0-distroless",
"image": "mcr.azk8s.cn/oss/istio/proxyv2:1.23.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.23.0, mcr.azk8s.cn/oss/istio/proxyv2:1.23.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.24.0-distroless

注意

如果在升级过程中遇到任何问题，请参阅有关排除网格修订升级故障的文章