Cloud Run for Anthos 的架构概览

本页面简要介绍 Cloud Run for Anthos 的架构，并介绍在 Google Kubernetes Engine 集群中启用 Cloud Run for Anthos 时发生的更改。

此信息适用于下列几类用户：

  • Cloud Run for Anthos 的新手用户。
  • 拥有 GKE 集群运行经验的操作员。
  • 为了设计更好的应用或配置 Cloud Run for Anthos 应用，需要详细了解 Cloud Run for Anthos 如何与 Kubernetes 集群集成的应用开发者。

默认安装的组件

将 Cloud Run for Anthos 作为插件安装到 Google Kubernetes Engine 集群时，系统会自动创建 knative-serving 和 gke-system 命名空间。以下组件部署到某一上述命名空间中：

  • 在 knative-serving 命名空间中运行的组件：

    • 激活程序：当 Pod 缩减至零或发送到修订版本的请求过多时，激活程序会暂时将请求加入队列，并向自动扩缩器发送指标以启动更多 Pod。自动扩缩器根据报告的指标和可用 Pod 扩缩修订版本后，激活程序会将队列中的请求转发到该修订版本。激活程序是一个数据平面组件；数据平面组件管理转发用户流量的所有功能和进程。
    • 自动扩缩器：汇总并处理来自激活程序和队列代理 Sidecar 容器（数据平面中强制执行请求并发限制的组件）的指标。然后，自动扩缩器会计算观察到的针对修订版本的并发，并根据所需的 Pod 数量调整部署的规模。如果 Pod 在修订版本中可用，则自动扩缩器是一个控制层面组件；否则，如果 Pod 缩减至零，则自动扩缩器是一个数据层面组件。
    • 控制器：创建和更新自动扩缩器的子资源以及服务对象。控制器是一个控制层面组件；控制层面组件管理所有相关功能和进程，以建立用户流量的请求路径。
    • Webhook：设置默认值，拒绝不一致和无效的对象，并对照 Cloud Run for Anthos 资源验证和更改 Kubernetes API 调用。Webhook 是一个控制平面组件。

  • 在 gke-system 命名空间中运行的组件：

    • 集群本地网关：数据平面中的负载平衡器，负责处理不同 Cloud Run for Anthos 之间的内部流量。您只能从 GKE 集群中访问集群本地网关，同时为了防止意外泄露隐私信息或内部进程，集群本地网关不会注册外部网域。
    • Istio 入站网关：数据层面内的负载平衡器，负责接收和处理来自集群外部的流量，包括来自外部或内部网络的流量。
    • Istio Pilot：配置集群本地网关和 Istio 入站网关以处理正确端点上的 HTTP 请求。Istio Pilot 是一个控制平面组件。如需了解详情，请参阅 Istio Pilot。

Cloud Run for Anthos 组件会在 GKE 控制层面集群进行任何更新时自动更新。如需了解详情，请参阅可用的 GKE 版本。

集群资源用量

初始安装 Cloud Run for Anthos 时大约需要 1.5 个虚拟 CPU 和 1 GB 集群内存。集群中的节点数不会影响 Cloud Run for Anthos 安装的空间和内存要求。

激活程序可以耗用最高 1000 milliCPU 和 600 MiB RAM 的请求。 当现有激活程序无法支持传入请求的数量时，系统将会再启动一个激活程序，这需要预留 300 milliCPU 和 60 MiB RAM。

Cloud Run for Anthos 服务创建的每个 Pod 都会创建一个队列代理 Sidecar，以强制执行请求并发限制。队列代理预留 25 milliCPU，但不预留内存。队列代理的耗用情况取决于队列中的请求数量以及请求的大小；它可以占用的 CPU 和内存资源没有限制。

创建 Service

Cloud Run for Anthos 服务架构示意图
Cloud Run for Anthos 服务架构（点击可放大）

Cloud Run for Anthos 通过定义一组自定义资源定义 (CRD)（服务、修订版本、配置和路由）来扩展 Kubernetes。这些 CRD 定义并控制您的应用在集群上的行为：

  • Cloud Run for Anthos 服务是由 Cloud Run for Anthos 定义的顶级自定义资源。它是一个用于管理工作负载整个生命周期的应用。您的服务可确保您的应用具有一个路由，一个配置和每次更新后的新修订版本。
  • “修订版本”是代码和配置的不可变时间点快照。
  • “配置”会保留最新修订版本的当前设置，并记录所有以前修订版本的历史记录。修改配置会创建新的修订版本。
  • “路由”定义 HTTP 端点，并将该端点与一个或多个请求转发到的修订版本相关联。

当用户创建 Cloud Run for Anthos 服务时，会发生以下情况：

  1. Cloud Run for Anthos 服务对象定义：

    1. 有关如何提供修订版本的配置。
    2. 此版服务的不可变修订版本。
    3. 管理指定的流量分配发送到修订版本的路由。

  2. 路由对象创建 VirtualService。VirtualService 对象会配置入站网关和集群本地网关，以将网关流量路由到正确的修订版本。

  3. 修订版本对象创建以下控制平面组件：Kubernetes Service 对象和 Deployment 对象。

  4. 网络配置为您的应用连接激活程序、自动扩缩器和负载平衡器。

请求处理

下图简要说明在 Google Kubernetes Engine 示例集群上，用户流量通过 Cloud Run for Anthos 数据层面组件的一种可能请求路径：

Cloud Run for Anthos 集群架构示意图
Cloud Run for Anthos 集群架构（点击可放大）

下图是上图的扩展，深入显示用户流量的请求路径，下文还对此进行了详细说明：

Cloud Run for Anthos 请求路径示意图
Cloud Run for Anthos 请求路径（点击可放大）

对于 Cloud Run for Anthos 请求路径：

  1. 流量通过以下路径到达：

    • 来自集群外部的流量的入站网关
    • 集群内流量的集群本地网关

  2. 用于指定流量路由规则的 VirtualService 组件会配置网关，以便将用户流量路由到正确的修订版本。

  3. Kubernetes Service 是一个控制平面组件，它根据处理流量时 Pod 的可用性确定请求路径中的下一步：

    • 如果修订版本中没有 Pod：

      1. 激活程序暂时将收到的请求加入队列，并将指标推送到自动扩缩器以扩容更多 Pod。
      2. 自动扩缩器会扩缩到 Deployment 中所需的 Pod 状态。
      3. Deployment 会创建更多 Pod 以接收其他请求。
      4. 激活程序会重试发送到队列代理 Sidecar 的请求。

    • 如果服务已扩容（Pod 可用），则 Kubernetes Service 会向队列代理 Sidecar 发送请求。

  4. 队列代理 Sidecar 强制执行容器可以一次处理的请求队列参数（单线程或多线程请求）。

  5. 如果队列代理 Sidecar 的请求数超出其处理能力，自动扩缩器会创建更多 Pod 来处理其他请求。

  6. 队列代理 Sidecar 将流量发送到用户容器。