共用方式為

升级基于 Istio 的服务网格插件以用于 Azure Kubernetes Service

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

有关基于 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。

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

    1. 验证 istiod pods：

      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. 如果启用了 Ingress，请验证 Ingress 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. 回滚金丝雀升级：如果您注意到工作负载的健康状态出现任何问题，可以回滚到上一版本的 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 都将由单个 ClusterIP 服务提供。

使用水平 Pod 自动缩放自定义进行次要修订升级

如果已为 Istiod 或入口网关自定义水平 Pod 自动缩放 (HPA) 设置，请注意以下行为，以了解如何在两个修订中应用 HPA 设置，从而在 Canary 升级期间保持一致性：

  • 如果在启动升级之前更新 HPA 规范，那么在安装新的控制平面的同时，现有（稳定）修订版本的设置将应用于金丝雀版本的 HPA。
  • 如果在 canary 升级正在进行时更新 HPA 规范，稳定版修订的 HPA 规范将具有优先级，并且会被应用到 canary 修订的 HPA。
    • 如果在升级期间更新稳定版本的 HPA，则 Canary 版本的 HPA 规范也会更新，以反映应用于稳定版本的新设置。
    • 如果在升级期间更新 Canary 修订版本的 HPA，则 Canary 修订版本的 HPA 规格将还原为稳定修订版本的 HPA 规格。

补丁版本升级

  • Istio 加载项修补程序版本可用性信息在 AKS 发行说明中发布。
  • 作为这些 AKS 版本的一部分，会自动推出适用于 istiod 和入口 Pod 的补丁，将遵循为群集设置的 default 计划内维护时段。
  • 用户需要在其工作负载中启动 Istio 代理的补丁，方法是重启 Pod 以便重新注入：

    • 检查用于新建或重启 Pod 的 Istio 代理版本。 在修补 istiod 和 Istio 入口 Pod 后，该版本与这些 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

注意

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

  • Last updated on