版本 1.11

配置代管式 Anthos Service Mesh

概览

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

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

前提条件

首先,本指南假定您已完成以下操作:

要求

限制

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

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

  • IstioOperator API 不受支持。

  • 代管式数据平面限制:

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

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

启用 Workload Identity

如果未启用 Workload Identity,请参阅在集群上启用 Workload Identity,以查看所需的 IAM 权限以及启用 gcloud 命令行。

下载安装脚本

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

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm
    
  2. 让该脚本可执行:

    chmod +x install_asm
    

配置每个集群

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

获取集群凭据

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

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 管理的数据平面,则必须选择这些选项。

  ./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。本指南中的步骤假定您从安装目录的根目录运行 istioctlistioctl 存在于安装目录的 /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 管理的 Sidecar 代理,而其余工作负载使用非托管式 Sidecar 代理。

  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 代管式控制层面支持单项目、单网络多主实例配置,但控制层面未安装在集群中。多主配置意味着,每个集群配置了对所有其他集群的 Secret,从而使每个集群能够发现所有其他集群的端点。

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

对于每个集群,通过为网格中的每个其他集群 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 标签:

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. 在 Cloud Console 中,查看控制层面指标:

    转到 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 管理的控制层面在没有被任何命名空间使用时会自动扩容到零,因此不需要卸载。

问题排查

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

后续步骤