Compartir a través de

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

  • Artículo

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

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

次要修订升级

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

如果群集当前使用受支持的 Istio 次要修订，则一次只允许升级一个次要修订。 如果群集使用的是不受支持的 Istio 修订，则必须升级到该 Kubernetes 修订支持的最低 Istio 次要修订。 之后，可以再次一次升级一个次要修订。

以下示例演示如何从版本 asm-1-20 升级到 asm-1-21。 所有次要升级的步骤都是相同的。

  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. 使用 az aks mesh upgrade start 启动从版本 asm-1-20 到 asm-1-21的 Canary 升级：

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

    Canary 升级意味着将 1.20 控制平面与 1.21 控制平面一起部署。 它们将继续共存，直到你完成或回滚升级。

  4. 验证与 asm-1-20 和 asm-1-21 对应的控制平面 Pod 是否存在：

    • 验证 istiod Pod：

      kubectl get pods -n aks-istio-system

      示例输出：

      NAME                                        READY   STATUS    RESTARTS   AGE
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

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

      kubectl get pods -n aks-istio-ingress

      示例输出：

      NAME                                                          READY   STATUS    RESTARTS   AGE
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

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

  5. 重新标记命名空间，以便任何新 Pod 都获得与新版本及其控制平面关联的 Istio 挎斗：

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

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

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

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

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

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

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

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

      • 将命名空间重新标记到上一个版本：

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

      • 通过再次重启这些工作负载，回滚工作负载以使用与 Istio 上一版本对应的挎斗：

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

      • 将控制平面回滚到上一版本：

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

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

注意

将命名空间移动到新版本时手动重新标记命名空间可能很繁琐且容易出错。 修订标记解决了这一问题。 修订标记是指向修订的稳定标识符，可用于避免重新标记命名空间。 网格运算符可以简单地将标记更改为指向新版本，而不是重新标记命名空间。 所有标有该标记的命名空间将同时更新。 但请注意，仍然需要重启工作负载，以确保注入正确版本的 istio-proxy 挎斗。

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

如果你当前正在使用 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.20.6-distroless",
"image": "mcr.azk8s.cn/oss/istio/proxyv2:1.20.6-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.20.0, mcr.azk8s.cn/oss/istio/proxyv2:1.20.6-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.20.0, mcr.azk8s.cn/oss/istio/proxyv2:1.20.7-distroless