使用 asmcli 预配代管式 Cloud 服务网格

概览

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

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

前提条件

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

使用要求

  • 一个或多个在受支持的 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 版本支持 GKE Autopilot 1.21.3+.

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

    • 如果您要加入的集群不在同一个项目中,则它们必须向同一舰队宿主项目注册,并且这些集群必须位于同一网络的共享 VPC配置中。
    • 对于单项目多集群环境,舰队项目可以与集群项目相同。如需详细了解舰队,请参阅 舰队概览
    • 对于多项目环境,我们建议您将舰队托管在与集群项目不同的项目中。如果您的组织 政策和现有配置允许,我们建议您使用 作为舰队宿主项目。如需了解详情,请参阅通过共享 VPC 设置集群
    • 如果贵组织使用 VPC Service Controls,并且您正在预配 已发布版本的 GKE 集群上的 Cloud Service Mesh 大于或等于 1.22.1-gke.10,那么您可能需要额外 配置步骤:

安装 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 支持的功能和限制。 请特别注意以下几点:

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

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

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

  • 在代管式控制平面的预配过程中,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 虚拟机)配置访问权限。

准备工作

配置 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 以指向集群。

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

下载安装工具

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

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
    
  2. 将该工具设置为可执行工具:

    chmod +x asmcli
    

配置每个集群

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

应用代管式控制平面

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

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

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

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

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

证书授权机构

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

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 的控制平面。在提供的占位符中输入值。
  ./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 将全面代管代理的升级。

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

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

代管式数据平面通过逐出正在运行的 Pod 来升级代理 代理的早期版本逐出操作是逐步完成的,以遵循 Pod 中断预算,并控制变化率。

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

  • 未注入的 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 维护窗口 才能接收通知。启用后,系统会在升级操作前至少两天发送通知。

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

  1. 进入通信页面。

    转到“通信”页面

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

每位想要接收通知的用户必须分别选择启用。如果您想 为这些通知设置电子邮件过滤器,主题行为:

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

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

Subject Line: 您的 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 服务示例

部署应用

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

受管 (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

如果您是使用 Managed 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
    

此时,您已成功配置了托管式 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 支持为 Cloud Storage 存储分区中的资源设置 requestslimits, Pod specGKE 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,使用注解配置资源 requestslimits 可能会超额预配资源。请使用图片模板方法避免这种情况。请参阅 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 分钟

    当您同时通过 Google 管理的控制平面和集群内控制平面运行 Cloud Service Mesh 时, 可以通过容器名称来区分指标例如,代管式指标具有 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

准备迁移

准备将应用从集群内 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

如果您是使用 Managed 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

问题排查

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

后续步骤