配置代管式 Anthos Service Mesh

警告： install_asm 和 istioctl install 命令在 Anthos Service Mesh 1.11 版本中弃用，在 1.12 版本中将不受支持。请更新您的脚本和工具以使用 asmcli。如需了解详情，请参阅改用 asmcli。 如需查看本指南的 asmcli 版本，请参阅配置代管式 Anthos Service Mesh。

概览

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

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

前提条件

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

• Cloud 项目。
• Cloud Billing 账号。
• 安装所需工具中指定的安装脚本、kpt 以及其他工具。

使用要求

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

• 您的集群必须启用 Workload Identity。如需了解 gcloud 命令，请参阅启用 Workload Identity。

• 由 Google 管理的数据平面要求您在部署由 Google 管理的控制平面时启用 Istio 容器网络接口 (CNI) 插件，如后文所述页面。

迁移

• 只有 1.9+ 版（通过 Mesh CA 安装）支持从集群内控制层面直接迁移/升级到 Google 管理的控制层面。
• 使用 Istio CA 进行的安装必须先迁移到 1.9+ Mesh CA。
• 支持间接迁移/升级，这意味着您可以遵循每个版本的标准 Anthos Service Mesh 升级路径，直到通过集群内控制层面达到 Anthos Service Mesh 1.11，然后才能迁移到 Google 管理的控制层面。

限制

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

• 代管式 Anthos Service Mesh 只能在单个 Google Cloud 项目中使用多个 GKE 集群。

• IstioOperator API 不受支持。

• 代管式数据平面限制：

  • 代管式数据平面的此预览版本仅适用于代管式控制层面的新部署。如果您之前部署了代管式控制层面，并且想要部署代管式数据层面，则必须重新运行安装脚本，如应用 Google 管理的控制层面。

  • 常规和快速发布渠道均提供托管式日期平面。

启用 Workload Identity

如果未启用 Workload Identity，请参阅在集群上启用 Workload Identity，以查看启用 Workload Identity 所需的 IAM 权限和 gcloud CLI。

注意：此 gcloud 命令可能需要 10-15 分钟才能完成，具体取决于您的集群的配置和工作负载。

下载安装脚本

注意：如需详细了解安装脚本（例如其验证和设置项目和集群的方式），请参阅了解脚本。

重要提示：安装脚本仅支持 Linux 操作系统。

1. 将安装 Anthos Service Mesh 1.11.8 的最新版脚本下载到当前工作目录中：

   curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
   

2. 让该脚本可执行：

   chmod +x install_asm
   

配置每个集群

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

获取集群凭据

检索相应的凭据。以下命令还将 kubectl 上下文指向目标集群。

注意：在以下命令中，您可以将 --zone 替换为 --region，具体取决于您的集群配置。

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

应用 Google 管理的控制层面

为将使用代管式 Anthos Service Mesh 的每个集群运行 install_asm 安装脚本。我们建议您在运行 install_asm 时添加以下两个选项：

• --option cni-managed此选项会启用 Istio 容器网络接口 (CNI) 插件。CNI 插件使用 CNCF CNI 接口（而不是具有高权限的 init 容器）配置进出 Sidecar 代理的网络流量重定向。

• --enable-registration：此标志会将集群注册到“队列”。

如果您还想部署 Google 管理的数据平面，则必须选择这些选项。如需查看选项的完整列表，请参阅 asmcli 参考页面。

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

该脚本会将用于配置代管式控制层面和安装 Istio 网关以及 istioctl 工具和示例应用的所有文件下载到指定的 --output_dir。本指南中的步骤假定您从安装目录的根目录运行 istioctl（istioctl 存在于安装目录的 /bin 子目录中）。

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

请注意，入站流量网关不会自动使用控制层面进行部署。通过分离入站流量网关和控制层面的部署，您可以更轻松地在生产环境中管理网关。如果集群需要入站网关，请参阅安装 Istio 网关。

应用 Google 管理的数据层面

本产品或功能须遵守服务专用条款的“通用服务条款”部分中的“非正式版产品条款”。 正式发布前产品和功能“按原样”提供，可能仅提供有限支持。 如需了解详情，请参阅发布阶段说明。

如果您希望 Google 管理代理的升级，请启用 Google 管理的数据平面。如果启用，Sidecar 代理和注入的网关将与代管式控制层面一起自动升级。

在功能预览中，托管式数据平面通过逐出运行旧版代理的 Pod 来升级代理。系统会按照 Pod 中断预算并控制更改速率按顺序执行逐出。

此托管数据平面预览版不管理以下内容：

• 未注入的 pod。
• 使用 istioctl kube-inject 手动注入的 pod。
• 作业
• 有状态集
• DaemonSet

如果您不想使用代管式数据层面或不想为所有命名空间启用该层面，则应该触发代理重启以从最新的代理映像中受益。控制层面会继续使用现有代理。

快速数据和常规发布渠道均支持代管式数据平面。

如需启用 Google 管理的数据层面，请执行以下操作：

1. 启用数据平面管理：

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

   或者，您可以为特定 Pod 启用 Google 管理的数据平面，只需使用相同的注解为其添加注解即可。当您为特定 Pod 添加注释时，该 Pod 使用 Google 管理的边车代理，而其余工作负载使用非代管式边车代理。

2. 对您希望代管数据平面的每个命名空间重复上一步骤。

3. 在机群中启用 Anthos Service Mesh：

   gcloud alpha container hub mesh enable --project=PROJECT_ID
   

数据平面控制器最多可能需要十分钟才能准备好管理集群中的代理。运行以下命令来检查状态：

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

当数据层面控制器准备就绪后，该命令将输出：Managed Data Plane is ready.

如果数据层面控制器在等待超过 10 分钟后仍未变为就绪状态，请参阅代管式数据层面状态中的问题排查提示。

如果您希望停用 Google 管理的数据层面，并还原为自行管理 Sidecar 代理，请更改注解：

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

安装 Istio Gateway（可选）

Anthos Service Mesh 允许您将网关部署和管理为服务网格的一部分。网关描述了在网格边缘运行的负载均衡器，用于接收传入或传出 HTTP/TCP 连接。网关是 Envoy 代理，可让您精确控制进出网格的流量。

我们建议您为网关创建单独的命名空间，这是最佳做法。请勿将网关部署到 istio-system 命名空间。

您可以按照以下步骤在集群中安装一个或多个 Istio Gateway 以处理典型的入站流量：

1. 选择以下两个选项之一来设置要在后续步骤中部署网关的命名空间。

   • 启用用于注入的命名空间：

     kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite
     

   OR

   • 仅为网关 pod 启用注入，但不对名称空间中的所有 pod 启用注入。此命令会移除所有注入标签，并且稍后会在 pod 上启用注入：

     kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-
     

2. 使用以下最小示例为网关创建 Deployment 和 Service：

   kubectl apply -f - << EOF
   apiVersion: v1
   kind: Service
   metadata:
     name: istio-ingressgateway
     namespace: GATEWAY_NAMESPACE
   spec:
     type: LoadBalancer
     selector:
       istio: ingressgateway
     ports:
     - port: 80
       name: http
     - port: 443
       name: https
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: istio-ingressgateway
     namespace: GATEWAY_NAMESPACE
   spec:
     selector:
       matchLabels:
         istio: ingressgateway
     template:
       metadata:
         annotations:
           # This is required to tell Anthos Service Mesh to inject the gateway with the
           # required configuration.
           inject.istio.io/templates: gateway
         labels:
           istio: ingressgateway
           istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
       spec:
         containers:
         - name: istio-proxy
           image: auto # The image will automatically update each time the pod starts.
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: istio-ingressgateway-sds
     namespace: GATEWAY_NAMESPACE
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: istio-ingressgateway-sds
     namespace: GATEWAY_NAMESPACE
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: istio-ingressgateway-sds
   subjects:
   - kind: ServiceAccount
     name: default
   EOF
   

3. 创建部署后，验证新服务是否正常运行：

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   验证类似于以下内容的输出：

   NAME                                      READY   STATUS    RESTARTS   AGE
   pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
   
   NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

您可以选择让托管数据平面控制器像管理服务一样管理网关的代理。如果您部署了管理的数据平面，并且希望管理网关代理，请按照应用 Google 管理的数据平面中的说明，为网关命名空间添加标签和注释。

如果您选择自行管理网关，则需要在发布新版本的 Anthos Service Mesh 时重启 GATEWAY_NAMESPACE 中的 Pod，以便它们选择新的控制层面配置。在重启 pod 之前，您应使用以下命令中提供的 Metrics Explorer 自定义查询来检查控制层面的版本，从而确认新的控制层面已经发布到您的集群：验证控制层面指标。

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

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

Anthos Service Mesh 代管式控制平面支持单项目、单网络多主实例配置，但控制平面未安装在集群中。

在继续操作之前，您应该已经按照上述步骤中的说明在每个集群上运行安装脚本。不需要指明集群是主要集群，这是默认行为。

对于每个集群，通过为网格中的每个其他集群 i=1..N 运行以下命令一次，启用端点发现：

1. 对于每个集群，请确保 kubectl 配置上下文指向当前集群：

   export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME
   

2. 通过为网格中的每个其他集群 i=1..N 运行以下命令一次，启用端点发现功能：

   export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i
   

   ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
     kubectl apply -f - --context=${CTX}
   

3. 运行以下命令来验证是否已创建 Secret：

   kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
   

   验证预期输出：

   NAME                                   TYPE     DATA   AGE
   istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s
   

4. 如果当前集群添加到现有多集群网格，请通过创建与所有其他集群中的当前集群相对应的 Secret，让所有其他集群发现其端点：

   ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
     kubectl apply -f - --context=${CTX_i}
   

5. 此外，您还可以验证另一个集群的 Secret：

   kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}
   

   验证预期输出：

   NAME                            TYPE     DATA   AGE
   istio-remote-secret-CLUSTER_NAME   Opaque   1      44s
   

如需了解详情以及包含两个集群的示例，请参阅启用端点发现功能。

部署应用

在部署应用之前，请从相应命名空间中移除任何以前的 istio-injection 标签，然后改为设置 istio.io/rev:asm-managed-rapid 标签：

注意：您可以忽略任何 label "istio-injection" not found 错误。

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

此时，您已成功配置 Anthos Service Mesh 代管式控制层面。现在，您可以部署应用，或者部署 Bookinfo 示例应用。

如果您在多集群设置中部署应用，请在所有集群中复制 Kubernetes 和控制层面配置，除非您计划将特定配置限制为部分集群。应用于特定集群的配置是该集群的真实来源。此外，如果集群还在其他命名空间中通过 Mesh CA 运行 Anthos Service Mesh 1.7、1.8 或更高版本，请验证应用可以与集群内控制层面控制的其他应用进行通信。

验证控制层面指标

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

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

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

   转到 Metrics Explorer

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

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

   同时将 Anthos 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 字段指示连接的代理数量。

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

将应用迁移到代管式 Anthos Service Mesh

托管式 Anthos Service Mesh 仅支持从使用 Mesh CA 的 Anthos Service Mesh 1.9 迁移。

如需迁移到代管式 Anthos Service Mesh，请执行以下步骤：

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

2. 如果您同时部署了 Google 管理的控制层面和数据平面：

   1. 启用数据平面管理：

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

   2. 在机群中启用 Anthos Service Mesh：

      gcloud alpha container hub mesh enable --project=PROJECT_ID
      

3. 将当前命名空间标签替换为 istio.io/rev:asm-managed-rapid 标签：

   kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
       --overwrite
   

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

8. 按照验证控制层面指标中的步骤操作，验证指标是否符合预期。

集群可以混合使用修订版本（例如 Anthos Service Mesh 1.7 和 1.8）以及集群控制层面。您可以结合使用不同的 Anthos Service Mesh 控制层面修订版本来混合使用命名空间。

如果您确定应用按预期运行，则在将所有命名空间切换到集群内控制层面后，可以移除集群内 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 修订版本。如需回滚，请重新运行 Anthos Service Mesh 安装命令，该命令会重新部署指回到集群内控制平面的网关：

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

成功时预期下列输出：

deployment.apps/istio-ingressgateway rolled back

将网关迁移到 Google 管理的控制层面

1. 使用文档为新版网关创建 Kubernetes Deployment。您必须使用服务配置中的 selector 字段配置现有的 Kubernetes 网关服务以同时选择旧版本和新版本。

2. 使用这些kubectl 规模，逐步扩充新部署，同时还要缩减旧部署，并检查是否有任何服务中断/停机时间。如果迁移成功，您应该在未出现服务中断的情况下访问零个旧实例。

卸载

Google 管理的控制层面在没有被任何命名空间使用时会自动扩容到零，因此不需要卸载。

问题排查

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

后续步骤

• 了解发布渠道