升级 Anthos Service Mesh

本页面介绍了如何：

• 运行 asmcli，以便从 Anthos Service Mesh 升级到 Anthos Service Mesh 1.14.6。

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

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

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

GKE

在 Google Kubernetes Engine 上，您可以直接从以下版本升级到 Anthos Service Mesh 1.14.6-asm.16：

1.12+

本地

在 GKE on VMware 和 Google Distributed Cloud Virtual for Bare Metal 上，您可以直接从以下版本升级到 Anthos Service Mesh 1.14.6-asm.16：

1.12+

GKE on AWS

在 GKE on AWS 上，您可以直接从以下版本升级到 Anthos Service Mesh 1.14.6-asm.16：

1.12+

Amazon EKS

如果您在 EKS 上安装了 Anthos Service Mesh 1.7，则需要在新集群上安装 Anthos Service Mesh 1.14。不支持从 Anthos Service Mesh 1.7 升级到 Anthos Service Mesh 1.14。

Microsoft AKS

如果您在 AKS 上安装了 Anthos Service Mesh 1.7，则需要在新集群上安装 Anthos Service Mesh 1.14。不支持从 Anthos Service Mesh 1.7 升级到 Anthos Service Mesh 1.14。

准备工作

警告：GitOps 工具（包括 Config Management、Argo CD、Terraform 和 Jenkins）可能会干扰 Anthos Service Mesh 安装、迁移或升级过程。为达到最佳效果，请在安装、迁移或升级 Anthos Service Mesh 之前停用 GitOps 工具。

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

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

警告：GitOps 工具（包括 Config Management、Argo CD、Terraform 和 Jenkins）可能会干扰 Anthos Service Mesh 安装、迁移或升级过程。为达到最佳效果，请在安装、迁移或升级 Anthos Service Mesh 之前停用 GitOps 工具。

控制层面自定义

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

注意：省略叠加文件会导致安装成功。不过，您的服务网格的配置与您预期的不同，因为在重新部署控制层面和 Ingress 网关时，省略的值将重置为默认值。

证书授权机构

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

升级 Anthos Service Mesh

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

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

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

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

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

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

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

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

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

集群 URI

在以下命令中，将 FLEET_PROJECT_ID 替换为舰队宿主项目的项目 ID，将集群 URI 替换为每个集群的集群名称、可用区或区域以及项目 ID。

./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

kubeconfig 文件

在以下命令中，将 FLEET_PROJECT_ID 替换为舰队宿主项目的项目 ID，将 PATH_TO_KUBECONFIG 替换为每个 kubeconfig 文件的路径。

./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 以使用默认平台支持的功能升级 Anthos Service Mesh，并启用 Anthos Service Mesh 证书授权机构 (Mesh CA) 作为证书授权。

平台说明：GKE on AWS、Amazon EKS 或 Microsoft AKS 不支持 Mesh CA。如果您在这些平台上运行 asmcli install 并指定 --ca mesh_ca，安装将失败。

GKE

运行以下命令以使用默认功能和 Mesh 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 mesh_ca

• --project_id、--cluster_name 和 --cluster_location 指定集群所在的项目 ID、集群名称以及集群区域或地区。
• --fleet_id：队列宿主项目的项目 ID。如果您未包含此选项，则 asmcli 会使用注册集群时在其中创建集群的项目。
• --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
注意：请记下此 --output_dir 目录。部署网关时将需要引用此目录。
• --enable_all 允许脚本执行以下操作：
  • 授予所需的 IAM 权限
  • 启用所需的 Google API。
  • 在集群上设置用于标识网格的标签。
  • 如果尚未注册集群，请注册集群。
• --ca mesh_ca将 Mesh CA 用作证书授权机构。在升级期间更改证书授权机构会导致停机。asmcli 将 Mesh CA 配置为使用机群工作负载身份

本地

在 GKE on VMware 或 Google Distributed Cloud Virtual for Bare Metal 上运行以下命令，以使用默认功能和 Mesh CA 升级控制平面。在提供的占位符中输入值。

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca mesh_ca将 Mesh CA 用作证书授权机构。在升级期间更改证书授权机构会导致停机。asmcli 将 Mesh CA 配置为使用集群工作负载身份

使用 CA Service 升级默认功能

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

GKE

运行以下命令以使用默认功能和 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

• --project_id、--cluster_name 和 --cluster_location 指定集群所在的项目 ID、集群名称以及集群区域或地区。
• --fleet_id：队列宿主项目的项目 ID。如果您未包含此选项，则 asmcli 会使用注册集群时在其中创建集群的项目。
• --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
注意：请记下此 --output_dir 目录。部署网关时将需要引用此目录。
• --enable_all 允许脚本执行以下操作：
  • 授予所需的 IAM 权限
  • 启用所需的 Google API。
  • 在集群上设置用于标识网格的标签。
  • 如果尚未注册集群，请注册集群。
• --ca gcp_cas 使用 Certificate Authority Service 作为证书授权机构。在升级期间更改证书授权机构会导致停机。asmcli 将 Certificate Authority Service 配置为使用舰队工作负载身份
• --ca_pool Certificate Authority Service CA 池的完整标识符。

本地

在 GKE on VMware 或 Google Distributed Cloud Virtual for Bare Metal 上运行以下命令，以使用默认功能和 Certificate Authority Service 升级控制平面。在提供的占位符中输入值。

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   ./asmcli install \
    --kubeconfig KUBECONFIG_FILE \
    --fleet_id FLEET_PROJECT_ID \
    --output_dir DIR_PATH \
    --enable_all \
    --ca gcp_cas \
    --platform multicloud \
    --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca gcp_cas 使用 Certificate Authority Service 作为证书授权机构。在升级期间更改证书授权机构会导致停机。asmcli 将 Certificate Authority Service 配置为使用舰队工作负载身份
   • --ca_pool Certificate Authority Service CA 池的完整标识符。

使用 Istio CA 升级默认特性

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

GKE

运行以下命令以使用默认功能和 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

• --project_id、--cluster_name 和 --cluster_location 指定集群所在的项目 ID、集群名称以及集群区域或地区。
• --fleet_id：队列宿主项目的项目 ID。如果您未包含此选项，则 asmcli 会使用注册集群时在其中创建集群的项目。
• --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
注意：请记下此 --output_dir 目录。部署网关时将需要引用此目录。
• --enable_all 允许脚本执行以下操作：
  • 授予所需的 IAM 权限
  • 启用所需的 Google API。
  • 在集群上设置用于标识网格的标签。
  • 如果尚未注册集群，请注册集群。
• --ca citadel 使用 Istio CA。在升级期间更改证书授权机构会导致停机。

本地

在 GKE on VMware 或 Google Distributed Cloud Virtual for Bare Metal 上运行以下命令，以使用默认功能和 Istio CA 升级控制平面。在提供的占位符中输入值。

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca citadel将 Istio CA 用作证书授权机构。
   • --ca_cert：中间证书
   • --ca_key：中间证书的密钥
   • --root_cert：根证书
   • --cert_chain：证书链

AWS

在 GKE on AWS 上运行以下命令，以使用默认功能和 Istio CA 升级控制平面。在提供的占位符中输入值。您可以选择为公共子网或专用子网启用 Ingress。

公开

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca citadel将 Istio CA 用作证书授权机构。
   • --ca_cert：中间证书
   • --ca_key：中间证书的密钥
   • --root_cert：根证书
   • --cert_chain：证书链

专用

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 将以下 YAML 保存到名为 istio-operator-internal-lb.yaml 的文件：

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     components:
       ingressGateways:
       - enabled: true
         k8s:
           serviceAnnotations:
             service.beta.kubernetes.io/aws-load-balancer-internal: "true"
         name: istio-ingressgateway
   

3. 运行 asmcli install：

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
     --custom_overlay istio-operator-internal-lb.yaml
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca citadel将 Istio CA 用作证书授权机构。
   • --ca_cert：中间证书
   • --ca_key：中间证书的密钥
   • --root_cert：根证书
   • --cert_chain：证书链

Amazon EKS

在 Amazon EKS 上运行以下命令，以使用默认功能和 Istio CA 升级控制平面。在提供的占位符中输入值。

平台说明：如果您在 EKS 上安装了 Anthos Service Mesh 1.7，则需要在新集群上安装 Anthos Service Mesh 1.14。不支持从 Anthos Service Mesh 1.7 升级到 Anthos Service Mesh 1.14。

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca citadel将 Istio CA 用作证书授权机构。
   • --ca_cert：中间证书
   • --ca_key：中间证书的密钥
   • --root_cert：根证书
   • --cert_chain：证书链

Microsoft AKS

在 Amazon EKS 上运行以下命令，以使用默认功能和 Istio CA 升级控制平面。在提供的占位符中输入值。

注意：如果您在 AKS 上安装了 Anthos Service Mesh 1.7，则需要在新集群上安装 Anthos Service Mesh 1.14。不支持从 Anthos Service Mesh 1.7 升级到 Anthos Service Mesh 1.14。

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca citadel将 Istio CA 用作证书授权机构。
   • --ca_cert：中间证书
   • --ca_key：中间证书的密钥
   • --root_cert：根证书
   • --cert_chain：证书链

使用可选功能升级

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

GKE

运行以下命令以使用可选功能安装控制层面。如需添加多个文件，请指定 --custom_overlay 和文件名，例如：--custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml。在提供的占位符中输入值。

./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

• --project_id、--cluster_name 和 --cluster_location 指定集群所在的项目 ID、集群名称以及集群区域或地区。
• --fleet_id：队列宿主项目的项目 ID。如果您未包含此选项，则 asmcli 会使用注册集群时在其中创建集群的项目。
• --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
注意：请记下此 --output_dir 目录。部署网关时将需要引用此目录。
• --enable_all 允许脚本执行以下操作：
  • 授予所需的 IAM 权限
  • 启用所需的 Google API。
  • 在集群上设置用于标识网格的标签。
  • 如果尚未注册集群，请注册集群。
• --ca mesh_ca将 Mesh CA 用作证书授权机构。在升级期间更改证书授权机构会导致停机。asmcli 将 Mesh CA 配置为使用机群工作负载身份
• --custom_overlay 指定叠加文件的名称。

Google Cloud 外部

在 GKE on VMware、Google Distributed Cloud Virtual for Bare Metal、GKE on AWS、Amazon EKS 或 Microsoft AKS 上运行以下命令。在提供的占位符中输入值。

平台说明：如果您在 EKS 上安装了 Anthos Service Mesh 1.7，则需要在新集群上安装 Anthos Service Mesh 1.14。不支持从 Anthos Service Mesh 1.7 升级到 Anthos Service Mesh 1.14。

1. 将当前上下文设置为用户集群：

   kubectl config use-context CLUSTER_NAME
   

2. 运行 asmcli install：

   ./asmcli install \
     --fleet_id FLEET_PROJECT_ID \
     --kubeconfig KUBECONFIG_FILE \
     --output_dir DIR_PATH \
     --platform multicloud \
     --enable_all \
     --ca mesh_ca \
     --custom_overlay OVERLAY_FILE
   

   • --fleet_id：队列宿主项目的项目 ID。
   • --kubeconfig kubeconfig 文件的完整路径。环境变量 $PWD 不适用于此处。 此外，使用“~”的相对 kubeconfig 文件位置将不起作用。
   • --output_dir添加此选项可指定 asmcli 在其中下载 anthos-service-mesh 软件包并提取安装文件的目录，其中包含 istioctl、示例和清单。否则，asmcli 会将文件下载到 tmp 目录。您可以指定相对路径或完整路径。环境变量 $PWD 不适用于此处。
   • --platform multicloud 指定平台是非 Google Cloud 平台，例如本地平台或多云平台。
   • --enable_all 允许脚本执行以下操作：
     • 授予所需的 IAM 权限
     • 启用所需的 Google API。
     • 在集群上设置用于标识网格的标签。
     • 如果尚未注册集群，请注册集群。
   • --ca mesh_ca将 Mesh CA 用作证书授权机构。在升级期间更改证书授权机构会导致停机。asmcli 将 Mesh CA 配置为使用机群工作负载身份
   • --custom_overlay 指定叠加文件的名称。

升级网关

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

警告：如果您使用 asmcli 以外的任何其他方法安装 Anthos Service Mesh，则除非您传入 --option legacy-default-ingressgateway 参数，否则系统会移除已安装的默认入站流量网关。

切换到新的控制层面

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

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

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

   NAME                                                 READY   STATUS    RESTARTS   AGE   REV
   istiod-asm-1146-16-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1139-10
   istiod-asm-1146-16-67998f4b55-r76kr           1/1     Running   0          68m   asm-1139-10
   istiod-1139-10-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1146-16
   istiod-1139-10-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1146-16

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

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

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

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

   如果您在输出中看到 "istio-injection not found"，则可以忽略它。这意味着命名空间之前没有 istio-injection 标签。如果命名空间同时具有 istio-injection 和修订版本标签，自动注入将失败，因此 Anthos 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 迁移还是从旧版 Anthos Service Mesh 升级。

      迁移

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

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

      升级

      1. 如果您是从旧版 Anthos 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-1146-16 的修订版本标签。要启用自动注入，请向一个或多个命名空间添加匹配的修订版本标签。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-1146-16
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1146-16
   istiod-asm-1146-16-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1139-10
   istiod-asm-1146-16-67998f4b55-r76kr          1/1     Running   0          68m   asm-1139-10
   istiod-asm-1139-10-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1146-16
   istiod-asm-1139-10-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1146-16

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

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

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 和修订版本标签，自动注入将失败，因此 Anthos 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>
      

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

      迁移

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

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

      升级

      如果您是从旧版 Anthos 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 迁移还是从旧版 Anthos Service Mesh 升级。

      迁移

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

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

      升级

      如果您是从旧版 Anthos 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 标志，则脚本会启用规范化服务控制器。我们建议将其保持启用状态，但如果您需要停用，请参阅启用和停用规范化服务控制器。