使用 asmcli 预配托管式 Cloud Service Mesh

已弃用 ：使用 asmcli 预配托管式 Cloud Service Mesh 将于 2024 年 8 月 22 日弃用，支持将于 2025 年 2 月结束。此更改只会影响 Google Cloud 集群。非Google Cloud 集群将继续照常使用 asmcli。

概览

具有 asmcli 的代管式 Cloud Service Mesh 是一个代管式控制平面，您只需配置一个代管式数据平面。Google 以向后兼容的方式为您处理可靠性、升级、扩缩和安全性问题。本指南介绍了如何使用 asmcli 在单集群或多集群配置中设置应用或将其迁移到代管式 Cloud Service Mesh。

注意 ：我们建议使用舰队功能 API 选项来配置托管式 Cloud Service Mesh，但您也可以使用本指南通过 asmcli 工具来配置托管式 Cloud Service Mesh。

如需了解代管式 Cloud Service Mesh 支持的功能和限制，请参阅代管式 Cloud Service Mesh 支持的功能。

前提条件

首先，本指南假定您已完成以下操作：

• Cloud 项目
• Cloud Billing 账号
• 获取预配 Cloud Service Mesh 所需的权限
• 安装所需工具中指定的 asmcli 安装工具、kpt 以及其他工具

为加快预配速度，您的集群必须启用 Workload Identity。如果未启用 Workload Identity，则预配会自动启用它。

使用要求

• 一个或多个在受支持的 GKE 版本中具有受支持区域的集群。

• 请注意，托管式 Cloud Service Mesh 使用 GKE 版本渠道来平衡稳定性和升级速度。对 Cloud Service Mesh 集群内组件（包括 CNI、MDPC、代理和 Istio CRD）所做的新更改将首先面向订阅了 GKE 快速渠道的集群发布。然后，如果这些版本表现出足够的稳定性，便会被提升到 GKE 常规渠道，最后再提升到 GKE 稳定渠道。

  • 代管式 Cloud Service Mesh 不支持安全地更改 GKE 版本渠道。
  • 如果您确实更改了 GKE 发布渠道，Cloud Service Mesh 会自动升级/降级集群内组件（CNI、MDPC、默认注入的代理版本和 Istio CRD），以与当前的 GKE 发布渠道保持一致。

• 确保集群有足够的容量来容纳代管式 Cloud Service Mesh 在集群中安装的所需组件。

  • kube-system 命名空间中的 mdp-controller 部署请求 cpu：50m，内存：128Mi。
  • kube-system 命名空间中的 istio-cni-node 守护进程集在每个节点上请求 cpu：100m，内存：100Mi。

• 确保已停用组织政策 constraints/compute.disableInternetNetworkEndpointGroup。如果此政策处于启用状态，ServiceEntry 可能无法正常运行。

• 确保从中预配代管式 Cloud Service Mesh 的客户端机器与 API 服务器之间有网络连接。

• 集群必须注册到舰队。此步骤可以在预配之前单独完成，也可以在预配过程中通过传递 --enable-registration 和 --fleet-id 标志来完成。

• 您的项目必须启用服务网格的舰队功能。您可以在预配过程中通过传递 --enable-gcp-components 或运行以下命令启用它：

  gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
  

  其中，FLEET_PROJECT_ID 是舰队宿主项目的 ID。

• 只有 GKE 1.21.3 及更高版本支持 GKE Autopilot。

• Cloud Service Mesh 可以在单项目单网络或多项目单网络环境中使用多个 GKE 集群。

  • 如果您要加入的集群不在同一个项目中，则它们必须向同一舰队宿主项目注册，并且这些集群必须位于同一网络的共享 VPC配置中。
  • 对于单项目多集群环境，舰队项目可以与集群项目相同。如需详细了解舰队，请参阅舰队概览。
  • 对于多项目环境，我们建议您将舰队托管在与集群项目不同的项目中。如果您的组织政策和现有配置允许，我们建议您将共享 VPC 项目用作舰队宿主项目。如需了解详情，请参阅通过共享 VPC 设置集群。
  • 如果您的组织使用 VPC Service Controls，并且要在版本高于或等于 1.22.1-gke.10 的 GKE 集群上预配 Cloud Service Mesh，则您可能需要执行额外的配置步骤：
    • 如果您要在常规或稳定发布版本上预配 Cloud Service Mesh，则在应用代管式控制平面时必须额外添加 --use-vpcsc 标志，并按照 VPC Service Controls（预览版）指南操作。否则，预配将无法通过安全控制。
    • 如果您要在快速发布版本上预配 Cloud Service Mesh，则在应用代管式控制平面时不需要额外添加 --use-vpcsc 标志，但需要按照 VPC Service Controls（正式版）指南操作。

安装 Cloud Service Mesh 所需的角色

下表介绍了安装代管式 Cloud Service Mesh 所需的角色。

角色名称	角色 ID	授予位置	说明
GKE Hub Admin	roles/gkehub.admin	舰队项目	拥有对 GKE Hub 及相关资源的完全访问权限。
Service Usage Admin	roles/serviceusage.serviceUsageAdmin	舰队项目	可启用、停用和检查使用方项目的服务状态、检查该项目的操作，以及使用其配额和结算服务。 ^（注意 1）
CA Service Admin ^Beta 版	roles/privateca.admin	舰队项目	具有对所有 CA 服务资源的完整访问权限。 ^（注意 2）

限制

注意 ：请注意以下特定于舰队的限制：特定 Cloud Service Mesh 中的所有集群都必须注册到同一舰队。集群不能注册到不同的舰队。 - 包含 Cloud Service Mesh 集群的项目中的所有集群都必须注册到同一舰队。

我们建议您查看 Cloud Service Mesh 支持的功能和限制列表。请特别注意以下几点：

• 不支持 IstioOperator API，因为它的主要目的是控制集群组件。

  注意 ：您仍然可以在不使用 IstioOperator API 的情况下启用可选功能，请参阅在代管式 Cloud Service Mesh 上启用可选功能。 您还可以使用 asmcli 附带的迁移工具自动转换其他 IstioOperator 可选功能，使其与代管式控制平面兼容。如需了解详情，请参阅从 IstioOperator 迁移。

• 对于 GKE Autopilot 集群，只有 GKE 1.23 或更高版本支持跨项目设置。

• 对于 GKE Autopilot 集群，为了适应 GKE Autopilot 资源限制，默认代理资源请求和限制设置为 500m CPU 和 512 Mb 内存。您可以使用自定义注入替换默认值。

• 在代管式控制平面的预配过程中，Istio CRD 将预配在指定集群中。如果集群中已有 Istio CRD，则它们将会被覆盖。

• Istio CNI 和 Cloud Service Mesh 与 GKE Sandbox 不兼容。因此，采用 TRAFFIC_DIRECTOR 实现的托管式 Cloud Service Mesh 不支持启用了 GKE Sandbox 的集群。

• asmcli 工具必须有权访问 Google Kubernetes Engine (GKE) 端点。您可以通过“跳转”服务器（例如提供特定访问权限的 Virtual Private Cloud [VPC] 中的 Compute Engine 虚拟机）配置访问权限。

准备工作

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

配置 gcloud

即使您使用的是 Cloud Shell，也请完成以下步骤。

1. 使用 Google Cloud CLI 进行身份验证：

   gcloud auth login --project PROJECT_ID
   

   其中，PROJECT_ID 是集群项目的唯一标识符。运行以下命令以获取 PROJECT_ID：

      gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
      ```
   

2. 更新组件：

   gcloud components update
   

3. 配置 kubectl 以指向集群。

   注意：如果集群是区域级集群，请使用 --region 取代 --zone。

   gcloud container clusters get-credentials CLUSTER_NAME \
        --zone CLUSTER_LOCATION \
        --project PROJECT_ID
   

下载安装工具

重要提示：asmcli 工具仅支持 Linux 操作系统。

1. 将该工具的最新版本下载到当前工作目录：

   curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
   

2. 将该工具设置为可执行工具：

   chmod +x asmcli
   

配置每个集群

请按照以下步骤为网格中的每个集群配置托管式 Cloud Service Mesh。

应用代管式控制平面

注意 ：或者，您可以使用 Fleet API 和 gcloud（而不是 asmcli）来设置托管式 Cloud Service Mesh。如需了解详情，请参阅使用 Fleet API 配置代管式 Cloud Service Mesh。

在应用代管式控制平面之前，您必须选择发布渠道。Cloud Service Mesh 渠道取决于您在预配托管式 Cloud Service Mesh 时使用的 GKE 集群渠道。请注意，不支持在同一集群中同时使用多个渠道。

为将使用代管式 Cloud Service Mesh 的每个集群运行安装工具。我们建议您添加以下两个选项：

警告：以下选项是必需的。如需查看选项的完整列表，请参阅 asmcli 参考文档页面。

• --enable-registration --fleet_id FLEET_PROJECT_ID 这两个标志会将集群注册到舰队，其中 FLEET_ID 是舰队宿主项目的 ID。如果使用单项目，FLEET_PROJECT_ID 与 PROJECT_ID 相同，则舰队宿主项目和集群项目相同。在多项目等更复杂的配置中，我们建议使用单独的舰队宿主项目。

• --enable-all：此标志会启用所需的组件和注册。

asmcli 工具使用 CLI 工具中的工具和逻辑直接配置代管式控制平面。根据您的首选 CA，使用以下说明集。

警告 ：为了让 Cloud Service Mesh 正常运行，您需要以提升的基于角色的访问权限控制 (RBAC) 权限（例如修改所有部署和创建 configmap）将 istio-cni-node DaemonSet 部署您的节点。这些权限是 istio-cni-node 管理 pod 生命周期和配置所必需的。

证书授权机构

选择要用于网格的证书授权机构。

Mesh CA

运行以下命令以使用默认功能和 Mesh CA 安装控制层面。在提供的占位符中输入值。

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

CA Service

1. 按照配置 Certificate Authority Service 中的步骤操作。
2. 运行以下命令以安装具有默认功能和 Certificate Authority Service 的控制平面。在提供的占位符中输入值。

注意：将 Certificate Authority Service 用作 MCP 多集群网格的一部分时，所有集群都必须将各自的从属 CA 池链接到同一根 CA 池。否则，所有这些用户都需要使用同一 CA 池。

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

该工具会将用于配置代管式控制平面的所有文件下载到指定的 --output_dir，并安装 istioctl 工具和示例应用。本指南中的步骤假定您从在运行 asmcli install 时指定的 --output_dir 位置运行 istioctl，其中 istioctl 存在于该位置的 <Istio release dir>/bin 子目录中。

如果您在同一集群上重新运行 asmcli，则该命令会覆盖现有的控制平面配置。如果要使用相同的配置，请务必指定相同的选项和标志。

验证已预配控制平面

几分钟后，验证控制平面状态是否为 ACTIVE：

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

输出类似于以下内容：

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

如果状态在几分钟后未达到 ACTIVE，请参阅检查代管式控制平面状态，详细了解可能的错误。

零触摸升级

安装代管式控制平面后，Google 会在新版本或补丁可用时自动升级。

代管式数据平面

如果您使用的是托管式 Cloud Service Mesh，Google 将全面代管代理的升级。

启用代管式数据平面功能后，通过重启工作负载来重新注入新版代理，边车代理和注入的网关将与代管式控制平面一起主动自动更新。此过程会在控制平面升级后开始，通常会在开始后 2 周内完成。

请注意，代管式数据平面依赖于 GKE 发布渠道。如果您在启用代管式数据平面时更改 GKE 发布渠道，代管式 Cloud Service Mesh 将更新所有现有工作负载的代理，就像发布代管式数据平面一样。

如果停用，代理管理将被动执行，由集群中的 Pod 的自然生命周期驱动，并且必须由用户手动触发以控制更新速率。

代管式数据平面通过逐出运行旧版代理的 Pod 来升级代理。逐出是逐渐完成的，遵循 Pod 中断预算并控制变化率。

注意 ：如果集群具有已定义的 GKE 维护窗口，Pod 逐出将在下一个可用维护窗口启动时开始，并且在所有代管式 Pod 更新完成之前不会暂停（通常为 12 小时）。CVE 相关的发布不会遵循维护窗口。

代管式数据平面不会代管以下各项：

• 未注入的 Pod
• 手动注入的 Pod
• 作业
• StatefulSet
• DaemonSet

如果您已在较旧的集群上预配了托管式 Cloud Service Mesh，则可以为整个集群启用数据平面管理：

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'

或者，您可以为特定控制平面修订版本、命名空间或 Pod 选择性地启用代管式数据平面，只需为其添加相同的注解即可。如果您选择性地控制各个组件，则优先顺序依次为控制平面修订版本、命名空间、Pod。

服务最多可能需要 10 分钟才能准备好管理集群中的代理。运行以下命令来检查状态：

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

预期输出

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

如果服务未在十分钟内准备就绪，请参阅代管式数据平面状态，了解后续步骤。

停用代管式数据平面（可选）

如果您要在新集群上预配托管式 Cloud Service Mesh，则可以完全停用托管式数据平面，也可以为单个命名空间或 pod 停用数据平面。对于默认或手动停用了代管式数据平面的现有集群，代管式数据平面将继续处于停用状态。

如需在集群级层停用代管式数据平面并还原为自行管理边车代理，请更改注解：

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

如需为命名空间停用代管式数据平面，请运行以下命令：

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

如需为 Pod 停用代管式数据平面，请执行以下命令：

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

启用维护窗口

如果您已配置 GKE 维护窗口，则在下一个可用维护窗口开始时，系统会开始执行主动升级，并且在所有受管 Pod 都更新完毕之前不会暂停（通常需要 12 小时）。CVE 相关的发布不遵循维护窗口。

Cloud Service Mesh 使用 GKE 维护时间窗口，以便与 GKE 保持一致。

启用维护通知

您可以请求在安排维护前一周收到关于即将进行的代管式数据平面维护的通知。默认情况下，系统不会发送维护通知。您还必须配置 GKE 维护窗口才能接收通知。启用后，系统会在升级操作前至少两天发送通知。

如需选择接收代管式数据平面维护通知，请执行以下操作：

1. 进入通信页面。

   转到“通信”页面

2. 在 Cloud Service Mesh 升级行中的电子邮件列下，选择单选按钮以开启维护通知。

每个希望接收通知的用户必须分别选择接收通知。如果您要为这些通知设置电子邮件过滤条件，则主题为：

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"。

以下示例展示了典型的代管式数据平面维护通知：

主题行：您的 Cloud Service Mesh 集群“<location/cluster-name>”即将升级

尊敬的 Cloud Service Mesh 用户：

您的集群 ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) 中的 Cloud Service Mesh 组件计划将于 ${scheduled_date_human_readable} ${scheduled_time_human_readable} 进行升级。

如需了解新的更新，请查看版本说明 (https://cloud.google.com/service-mesh/docs/release-notes)。

如果此维护被取消，系统会再向您发送一封电子邮件。

此致

Cloud Service Mesh 团队

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 我们向您发送这封重要的服务通知，目的是让您了解关于 Google Cloud Platform 或您账号的重大变化。 您可以修改您的用户偏好设置以停止接收维护期通知：https://console.cloud.google.com/user-preferences/communication?project=${project_id}

配置端点发现（仅适用于多集群安装）

如果您的网格只有一个集群，请跳过这些多集群步骤并继续部署应用或迁移应用。

在继续操作之前，请确保已在每个集群上配置 Cloud Service Mesh。

注意： 如需详细了解端点发现，请参阅具有多个控制平面的端点发现。

公共集群

在公共集群之间配置端点发现

如果您在公共集群（非专用集群）上执行操作，则可以在公共集群之间配置端点发现或者只是在公共集群之间启用端点发现。

专用集群

在专用集群之间配置端点发现

使用 GKE 专用集群时，必须将集群控制平面端点配置为公共端点，而不是专用端点。请参阅在专用集群之间配置端点发现。

如需查看包含两个集群的示例应用，请参阅 HelloWorld 服务示例。

注意：HelloWorld 服务示例使用 Docker Hub。默认情况下，在专用集群中，容器运行时可以从 Artifact Registry 中拉取容器映像。容器运行时无法从互联网上的任何其他容器映像注册表中拉取映像。您可以下载映像并推送到 Artifact Registry，或使用 Cloud NAT 为某些专用节点提供出站互联网访问权限。如需了解详情，请参阅迁移外部容器和创建专用集群。

部署应用

启用用于注入的命名空间。具体步骤取决于您的控制平面实现。

受管理 (TD)

1. 将默认注入标签应用于命名空间：

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

受管理（Istiod）

推荐：运行以下命令可将默认注入标签应用于命名空间：

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

如果您是使用托管式 Istiod 控制平面的现有用户：我们建议您使用默认注入，但也支持基于修订版本的注入。请按照以下说明操作：

1. 运行以下命令以查找可用的发布渠道：

   kubectl -n istio-system get controlplanerevision
   

   输出类似于以下内容：

   NAME                AGE
   asm-managed-rapid   6d7h
   

   注意：如果上述列表中显示了两个控制平面修订版本，请移除其中一个。不支持在集群中使用多个控制平面渠道。

   在输出中，NAME 列的值是与 Cloud Service Mesh 版本可用的发布版本对应的修订版本标签。

2. 将修订版本标签应用于命名空间：

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

使用以下命令验证是否已正确应用命名空间标签。

  kubectl get namespace -L istio-injection

输出示例：

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

至此，您已成功配置代管式 Cloud Service Mesh。如果添加了标签的命名空间中有任何现有工作负载，则需进行重启以注入代理。

如果您在多集群设置中部署应用，请在所有集群中复制 Kubernetes 和控制平面配置，除非您计划将特定配置限制为部分集群。应用于特定集群的配置是该集群的真实来源。

自定义注入（可选）

您可以替换默认值和自定义注入设置，但这可能会导致不可预见的配置错误，并会导致 Sidecar 容器问题。在自定义注入之前，请阅读示例后的信息，了解特定设置和建议的说明。

每个 pod 的配置都可用于覆盖各个 pod 上的这些选项。这是通过将 istio-proxy 容器添加到 pod 来实现的。Sidecar 注入会将此处定义的任何配置视为对默认注入模板的覆盖项。

例如，以下配置可自定义各种设置，包括降低 CPU 请求、添加卷装载以及添加 preStop 钩子：

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

一般而言，您可以设置 Pod 中的任何字段。但是，请务必注意某些字段：

• Kubernetes 要求在运行注入之前设置 image 字段。虽然您可以将特定映像设置为替换默认映像，但建议将 image 设置为 auto，这会使 Sidecar 注入器自动选择要使用的映像。
• containers 中的某些字段取决于相关设置。例如，必须小于或等于 CPU 限制。如果这两个字段都未正确配置，则 pod 可能无法启动。
• Kubernetes 可让您为 Pod spec 中的资源设置 requests 和 limits。GKE Autopilot 仅考虑 requests。如需了解详情，请参阅在 Autopilot 中设置资源限制。

此外，某些字段可通过 pod 上的注解进行配置，但建议您使用上述方法自定义设置。请对以下注释格外小心：

• 对于 GKE Standard，如果设置了 sidecar.istio.io/proxyCPU，请务必明确设置 sidecar.istio.io/proxyCPULimit。否则，Sidecar 的 CPU 限制将设置为无限制。
• 对于 GKE Standard，如果设置了 sidecar.istio.io/proxyMemory，请务必明确设置 sidecar.istio.io/proxyMemoryLimit。否则，Sidecar 的内存限制将设置为无限制。
• 对于 GKE Autopilot，使用注解配置资源 requests 和 limits 可能会超额预配资源。请使用图片模板方法避免这种情况。请参阅 Autopilot 中的资源修改示例。

例如，请参阅以下资源注解：

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

验证控制层面指标

您可以在 Metrics Explorer 中查看控制平面和数据平面的版本。

如需验证您的配置是否按预期运行，请执行以下操作：

1. 在 Google Cloud 控制台中，查看控制平面指标：

   转到 Metrics Explorer

2. 选择您的工作区，并使用以下参数添加自定义查询：

   • 资源类型：Kubernetes 容器
   • 指标：代理客户端
   • 过滤条件：container_name="cr-REVISION_LABEL"
   • 分组依据：revision 标签和 proxy_version 标签
   • 聚合器：总和
   • 时间段：1 分钟

   同时将 Cloud Service Mesh 与 Google 管理的控制平面和集群内控制平面一起运行时，您可以根据指标的容器名称来区分指标。例如，代管式指标具有 container_name="cr-asm-managed"，而非代管式指标的值为 container_name="discovery"。如需同时显示这两项的指标，请移除 container_name="cr-asm-managed" 上的过滤条件。

3. 在 Metrics Explorer 中检查以下字段，验证控制平面版本和代理版本：

   • revision 字段指示控制平面版本。
   • proxy_version 字段指示 proxy_version。
   • value 字段指示连接的代理数量。

   如需了解当前渠道到 Cloud Service Mesh 版本的映射，请参阅每个渠道的 Cloud Service Mesh 版本。

将应用迁移到托管式 Cloud Service Mesh

警告 ：在迁移过程中，Istio CRD 将安装在指定集群中。如果集群中已有 Istio CRD，则它们将会被覆盖。

准备迁移

如需准备将应用从集群内 Cloud Service Mesh 迁移到代管式 Cloud Service Mesh，请执行以下步骤：

1. 按照应用 Google 管理的控制平面部分中的说明运行工具。

2. （可选）如果要使用 Google 管理的数据平面，请启用数据平面管理：

     kubectl annotate --overwrite controlplanerevision REVISION_TAG \
     mesh.cloud.google.com/proxy='{"managed":"true"}'
   

迁移应用

如需将应用从集群内 Cloud Service Mesh 迁移到代管式 Cloud Service Mesh，请执行以下步骤：

1. 替换当前命名空间标签。具体步骤取决于您的控制平面实现。

受管理 (TD)

1. 将默认注入标签应用于命名空间：

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

受管理（Istiod）

推荐：运行以下命令可将默认注入标签应用于命名空间：

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

如果您是使用托管式 Istiod 控制平面的现有用户：我们建议您使用默认注入，但也支持基于修订版本的注入。请按照以下说明操作：

1. 运行以下命令以查找可用的发布渠道：

   kubectl -n istio-system get controlplanerevision
   

   输出类似于以下内容：

   NAME                AGE
   asm-managed-rapid   6d7h
   

   注意：如果上述列表中显示了两个控制平面修订版本，请移除其中一个。不支持在集群中使用多个控制平面渠道。

   在输出中，NAME 列的值是与 Cloud Service Mesh 版本可用的发布版本对应的修订版本标签。

2. 将修订版本标签应用于命名空间：

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

1. 对命名空间中的部署执行滚动升级：

   kubectl rollout restart deployment -n NAMESPACE
   

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

3. 如果您在其他命名空间中存在工作负载，请对每个命名空间重复上述步骤。

4. 如果您在多集群设置中部署应用，请在所有集群中复制 Kubernetes 和 Istio 配置，除非有合适的配置限制只限于部分集群使用。应用于特定集群的配置是该集群的真实来源。

如果您确定应用按预期运行，则在将所有命名空间切换到代管式控制平面后，可以移除集群内 istiod，或将其另存为备份 - istiod 会自动缩减使用的资源。如需将其移除，请跳至删除旧的控制平面。

如果遇到问题，您可以使用解决代管式控制平面问题中的信息识别并解决问题，并在必要时回滚到先前版本。

删除旧的控制平面

安装并确认所有命名空间都使用 Google 管理的控制平面后，您可以删除旧的控制平面。

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

如果您使用的是 istioctl kube-inject（而不是自动注入），或者您安装了其他网关，请检查控制平面的指标，并验证连接的端点数量是否为零。

回滚

如果您需要回滚到先前的控制平面版本，请执行以下步骤：

1. 更新要用旧版控制平面注入的工作负载：在以下命令中，修订版本值 asm-191-1 仅用作示例。将示例值替换为前面的控制平面的修订版本标签。

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
   

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

   kubectl rollout restart deployment -n NAMESPACE
   

代管式控制平面会自动扩容到零，在不使用时不使用任何资源。更改 Webhook 和预配将会保留，不会影响集群行为。

网关现已设置为 asm-managed 修订版本。如需回滚，请重新运行 Cloud Service Mesh 安装命令，该命令会重新部署指回到集群内控制平面的网关：

kubectl -n istio-system rollout undo deploy istio-ingressgateway

成功时预期下列输出：

deployment.apps/istio-ingressgateway rolled back

卸载

当没有命名空间使用代管式控制平面时，该控制平面会自动扩缩为零。如需了解详细步骤，请参阅卸载 Cloud Service Mesh。

问题排查

如需在使用代管式控制平面时识别和解决问题，请参阅解决代管式控制平面问题。

后续步骤

• 了解发布渠道。
• 从 IstioOperator 迁移。
• 将网关迁移到代管式控制平面。
• 了解如何启用可选的代管式 Cloud Service Mesh 功能，例如：
  • Envoy 访问日志
  • 跟踪
  • Distroless 映像
  • 最终用户身份验证