升级 Cloud Service Mesh

本页面介绍了如何：

• 运行 asmcli 以从 Cloud Service Mesh 升级到 Cloud Service Mesh1.18.7。

• （可选）部署入站流量网关。

• 执行 Canary 升级，将工作负载迁移到新控制层面。

您可以从哪些 Cloud Service Mesh 版本升级因平台而异。

准备工作

开始之前，请确保执行以下操作：

• 查看前提条件。
• 查看规划升级中的信息。
• 安装所需的工具。
• 下载 asmcli。
• 授予集群管理员权限。
• 验证项目和集群。

控制层面自定义

如果您自定义了先前的安装，在升级至新的 Cloud Service Mesh 版本或从 Istio 迁移时，需要相同的自定义。如果您通过向 istioctl install 添加 --set values 标志来自定义安装，则必须将这些设置添加到 IstioOperator YAML 文件（称为 叠加文件。您可以在运行脚本时使用 --custom_overlay 选项和文件名来指定叠加文件。脚本将叠加文件传递给 istioctl install。

证书授权机构

在升级过程中更改证书授权机构 (CA) 会导致停机。升级期间，mTLS 流量会中断，直到所有工作负载切换为使用具有新 CA 的新控制层面。

升级 Anthos Service Mesh

以下部分概述了如何升级 Cloud Service Mesh：

1. 如果要升级 GKE 上使用 Cloud Service Mesh 证书授权机构的多集群网格，请运行 asmcli create-mesh 将多集群网格配置为信任舰队工作负载身份，以便在升级时跨集群负载均衡无需停机。

2. 运行 asmcli install 以在单个集群上安装 Cloud Service Mesh。有关命令行示例，请参阅以下部分。这些示例同时包含可能必需的必需参数和可选参数。我们建议您始终指定 output_dir 参数，以便轻松找到示例网关和 istioctl 等工具。请在右侧的导航栏中查看示例列表。

3. （可选）安装或升级入站流量网关。默认情况下，asmcli 不会安装 istio-ingressgateway。我们建议您单独部署和管理控制平面和网关。如果您需要让默认 istio-ingressgateway 随集群内控制平面安装，请添加 --option legacy-default-ingressgateway 参数。

4. 如需完成 Cloud Service Mesh 的设置，您需要启用自动 Sidecar 注入并部署或重新部署工作负载。

将多集群网格配置为信任舰队工作负载身份

如果要升级 GKE 上使用 Cloud Service Mesh 证书授权机构作为证书授权机构的多集群网格，则需要先运行 asmcli create-mesh，然后再升级每个集群。此命令将 Cloud Service Mesh 证书授权机构配置为在升级后使用舰队工作负载身份池 FLEET_PROJECT_ID.svc.id.goog 作为信任网域。asmcli create-mesh 命令会执行以下操作：

• 将所有集群注册到同一舰队。
• 将网格配置为信任舰队工作负载身份。
• 创建远程 Secret。

您可以指定每个集群的 URI 或 kubeconfig 文件的路径。

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

使用默认功能和 Mesh CA 升级

本部分介绍如何运行 asmcli 以使用默认平台支持的功能升级 Cloud Service Mesh，并启用 Cloud Service Mesh 证书授权机构作为证书授权。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

使用 CA Service 升级默认功能

本部分介绍如何运行 asmcli 以使用默认平台支持的功能升级 Cloud Service Mesh，并启用 Certificate Authority Service。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL

使用 Istio CA 升级默认特性

本部分介绍如何运行 asmcli 以使用默认平台支持的功能升级 Cloud Service Mesh 并启用 Istio CA。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel

使用可选功能升级

叠加文件是一个 YAML 文件，其中包含您传递给 asmcli 以配置控制平面的 IstioOperator 自定义资源 (CR)。您可以替换默认控制平面配置，并通过将 YAML 文件传递给 asmcli 来启用可选功能。您可以叠加多个文件，每个叠加文件会覆盖之前各层的配置。

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

升级网关

如果已部署网关，则还需要升级这些网关。如需进行简单升级，请按照安装和升级网关指南中的“就地升级”部分进行操作。

切换到新的控制层面

1. 获取 istiod 上的修订版本标签。

   kubectl get pod -n istio-system -L istio.io/rev
   

   此命令的输出类似如下所示。

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1187-26-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1178-20
   istiod-asm-1187-26-67998f4b55-r76kr           1/1     Running   0          68m   asm-1178-20
   istiod-1178-20-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1187-26
   istiod-1178-20-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1187-26

   1. 在输出中的 REV 列下，记下新版本的修订版标签的值。在此示例中，该值为 asm-1187-26。

   2. 另请注意旧版 istiod 的修订版本标签中的值。 将工作负载移至新版本后，您需要使用此值删除旧版本的 istiod。在示例输出中，旧版本的修订版本标签值为 asm-1178-20。

2. 将修订版本标签添加到应用命名空间，并移除 istio-injection 标签（如果存在）。在以下命令中，将 REVISION 更改为与 istiod 的新修订版本匹配的值。

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   如果您在输出中看到 "istio-injection not found"，则可以忽略它。这意味着命名空间之前没有 istio-injection 标签。如果命名空间同时具有 istio-injection 和修订版本标签，自动注入行为未定义，因此 Cloud Service Mesh 文档中的所有 kubectl label 命令都会明确确保仅设置一个标签。

3. 重启 pod 以触发重新注入。

   kubectl rollout restart deployment -n NAMESPACE

4. 测试您的应用，验证工作负载是否正常工作。

5. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

6. 如果您确信应用按预期正常运行，请继续执行转换到新版 istiod 的步骤。如果您的应用出现问题，请按照以下步骤回滚。

   完成转换

   如果您确信应用按预期正常运行，请移除旧控制平面以完成到新版本的转换。

   1. 切换到 anthos-service-mesh GitHub 代码库中的文件所在的目录。

   2. 配置验证 Webhook 以使用新的控制平面：

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. 迁移默认标记：

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>
      

   4. 删除 istiod 的旧版本。要使用的命令取决于您是从 Istio 迁移还是从旧版 Cloud Service Mesh 升级。

      迁移

      如果您是从 Istio 迁移，旧的 istio-ingressgateway 没有修订版本标签：

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      升级

      1. 如果您是从旧版 Cloud Service Mesh 升级，在以下命令中，请确保 OLD_REVISION 与旧版 istiod 的修订版本标签匹配：

         kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
         

      2. 删除旧修订版本的 validatingwebhookconfiguration 资源：

         kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found
         

   5. 移除旧版 IstioOperator 配置：

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      预期输出如下所示：

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   回滚

   如果您在使用新版 istiod 测试应用时遇到问题，请按照以下步骤回滚到之前的版本：

   1. 重新为您的命名空间添加标签，以启用旧版 istiod 的自动注入。使用的命令取决于您在旧版本使用的是修订版本标签还是 istio-injection=enabled。

      • 如果您使用修订版本标签来进行自动注入，请使用以下命令：

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • 如果您使用的是 istio-injection=enabled，请使用以下命令：

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      预期输出：

      namespace/NAMESPACE labeled

   2. 确认命名空间上的修订版本标签与旧版 istiod 的修订版本标签一致：

      kubectl get ns NAMESPACE --show-labels
      

   3. 重启 pod 以触发重新注入，以使代理具有之前的版本：

      kubectl rollout restart deployment -n NAMESPACE
      

   4. 移除新版 istiod。确保以下命令中的 REVISION 值正确无误。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   5. 移除新版 IstioOperator 配置。

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      预期输出如下所示：

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   6. 如果您未添加 --disable_canonical_service 标志，则 asmcli 会启用规范化服务控制器。我们建议将其保持启用状态，但如果您需要停用，请参阅启用和停用规范化服务控制器。

   7. 如果您部署了网关，请务必更改命名空间或部署上的修订版本标签以匹配先前版本的 istiod。按照安装和升级网关指南中“就地升级”部分中所述的相同流程执行操作。

部署和重新部署工作负载

您需要启用自动边车代理注入（自动注入），才能完成安装（或升级）。从 OSS Istio 迁移和升级遵循基于修订版本的升级流程（在 Istio 文档中称为“Canary 升级”）。使用基于修订版本的升级时，新版本的控制平面会与现有控制平面一起安装。然后，您可以将一部分工作负载迁移到新版本，这样，您就可以先通过一小部分工作负载监控升级的影响，然后再将所有流量迁移到新版本。

该脚本在 istiod 上设置格式为 istio.io/rev=asm-1187-26 的修订版本标签。要启用自动注入，请向一个或多个命名空间添加匹配的修订版本标签。Sidecar 注入器网络钩子会使用修订版本标签将注入的 Sidecar 与特定 istiod 修订版本相关联。添加标签后，重启命名空间中的 pod 以注入 Sidecar。

1. 获取 istiod 和 istio-ingressgateway 上的修订版本标签。

   kubectl get pod -n istio-system -L istio.io/rev
   

   此命令的输出类似如下所示。

   NAME                                                READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-65d884685d-6hrdk               1/1     Running   0          67m
   istio-ingressgateway-65d884685d-94wgz               1/1     Running   0          67m
   istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb      1/1     Running   0          5s    asm-1187-26
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1187-26
   istiod-asm-1187-26-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1178-20
   istiod-asm-1187-26-67998f4b55-r76kr          1/1     Running   0          68m   asm-1178-20
   istiod-asm-1178-20-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1187-26
   istiod-asm-1178-20-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1187-26

   1. 在输出中的 REV 列下，记下新版本的修订版标签的值。在此示例中，该值为 asm-1187-26。

   2. 另请注意旧版 istiod 的修订版本标签中的值。 将工作负载移至新版本后，您需要使用此值删除旧版本的 istiod。在示例输出中，旧版本的修订版本标签值为 asm-1178-20。

2. 将 istio-ingressgateway 切换到新的修订版本。在以下命令中，将 REVISION 的值更改为新版本修订版本标签的值。

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION"}]'

   预期输出：service/istio-ingressgateway patched

3. 将修订版本标签添加到命名空间，并移除 istio-injection 标签（如果存在）。在以下命令中，将 REVISION 更改为与 istiod 的新修订版本匹配的值。

   kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

   如果您在输出中看到 "istio-injection not found"，则可以忽略它。这意味着命名空间之前没有 istio-injection 标签。如果命名空间同时具有 istio-injection 和修订版本标签，自动注入行为未定义，因此 Cloud Service Mesh 文档中的所有 kubectl label 命令都会明确确保仅设置一个标签。

4. 重启 pod 以触发重新注入。

   kubectl rollout restart deployment -n NAMESPACE

5. 测试您的应用，验证工作负载是否正常工作。

6. 如果您的其他命名空间中存在工作负载，请重复上述步骤以标记命名空间并重启 Pod。

7. 如果您确信应用按预期正常运行，请继续执行转换到新版 istiod 的步骤。如果您的应用出现问题，请按照以下步骤回滚。

   完成转换

   如果您确信应用按预期正常运行，请移除旧控制平面以完成到新版本的转换。

   1. 切换到 anthos-service-mesh GitHub 代码库中的文件所在的目录。

   2. 配置验证 Webhook 以使用新的控制平面。

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. 迁移默认标记。

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite
      

   4. 删除旧 istio-ingressgateway 部署。要运行的命令取决于您是从 Istio 迁移还是从旧版 Cloud Service Mesh 升级：

      迁移

      如果您是从 Istio 迁移，旧的 istio-ingressgateway 没有修订版本标签。

      kubectl delete deploy/istio-ingressgateway -n istio-system
      

      升级

      如果您是从旧版 Cloud Service Mesh 升级，请在以下命令中将 OLD_REVISION 替换为旧版 istio-ingressgateway 的修订版本标签。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
      

   5. 删除 istiod 的旧版本。要使用的命令取决于您是从 Istio 迁移还是从旧版 Cloud Service Mesh 升级。

      迁移

      如果您是从 Istio 迁移，旧的 istio-ingressgateway 没有修订版本标签。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
      

      升级

      如果您是从旧版 Cloud Service Mesh 升级，在以下命令中，请确保 OLD_REVISION 与旧版 istiod 的修订版本标签匹配。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
      

   6. 移除旧版 IstioOperator 配置。

      kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
      

      预期输出如下所示：

      istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted

   回滚

   如果您在使用新版 istiod 测试应用时遇到问题，请按照以下步骤回滚到之前的版本：

   1. 重新为您的命名空间添加标签，以启用旧版 istiod 的自动注入。使用的命令取决于您在旧版本使用的是修订版本标签还是 istio-injection=enabled。

      • 如果您使用修订版本标签来进行自动注入，请使用以下命令：

        kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
        

      • 如果您使用的是 istio-injection=enabled，请使用以下命令：

        kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
        

      预期输出：

      namespace/NAMESPACE labeled

   2. 确认命名空间上的修订版本标签与旧版 istiod 的修订版本标签一致：

      kubectl get ns NAMESPACE --show-labels
      

   3. 重启 pod 以触发重新注入，以使代理具有之前的版本：

      kubectl rollout restart deployment -n NAMESPACE
      

   4. 移除新的 istio-ingressgateway 部署。确保以下命令中的 REVISION 值正确无误。

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION -n istio-system --ignore-not-found=true
      

   5. 移除新版 istiod。确保以下命令中的 REVISION 值正确无误。

      kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true
      

   6. 移除新版 IstioOperator 配置。

      kubectl delete IstioOperator installed-state-REVISION -n istio-system
      

      预期输出如下所示：

      istiooperator.install.istio.io "installed-state-REVISION" deleted

   7. 如果您未添加 --disable_canonical_service 标志，则脚本会启用规范化服务控制器。我们建议将其保持启用状态，但如果您需要停用，请参阅启用和停用规范化服务控制器。