Knative serving 的架构概览

本页面简要介绍 Knative serving 的架构,并介绍在 Google Kubernetes Engine 集群中启用 Knative serving 时发生的更改。

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

  • 刚开始使用 Knative serving 的用户。
  • 拥有 GKE 集群运行经验的操作员。
  • 为了设计更好的应用或配置其 Knative serving 应用,需要详细了解 Knative serving 如何与 Kubernetes 集群集成的应用开发者。

默认安装的组件

Knative serving 安装到集群中,以用于连接和管理无状态工作负载。Knative 组件是在 knative-serving 命名空间中创建的。

Knative serving 使用 Cloud Service Mesh 来路由流量。默认情况下,Cloud Service Mesh 会在 istio-system 命名空间中安装组件。

下面列出了 Knative serving 和 Cloud Service Mesh 安装的组件:

  • Knative serving 在 knative-serving 命名空间中安装的组件:

    • Activator:当 Pod 缩减至零或由于发送到修订版本的请求过多而过载时,激活程序会暂时将请求加入队列,并向自动扩缩器发送指标以启动更多 Pod。自动扩缩器根据报告的指标和可用 Pod 扩缩修订版本后,激活程序会将队列中的请求转发到该修订版本。激活程序是一个数据平面组件;数据平面组件管理转发用户流量的所有功能和进程。
    • 自动扩缩器:汇总并处理来自激活程序和队列代理 Sidecar 容器(数据平面中强制执行请求并发限制的组件)的指标。然后,自动扩缩器会计算观察到的针对修订版本的并发,并根据所需的 Pod 数量调整部署的规模。如果 Pod 在修订版本中可用,则自动扩缩器是一个控制平面组件;否则,如果 Pod 缩减至零,则自动扩缩器是一个数据平面组件。
    • 控制器:创建和更新自动扩缩器的子资源以及服务对象。控制器是一个控制平面组件;控制平面组件管理所有相关功能和进程,以建立用户流量的请求路径。
    • 指标收集器:从 Knative serving 组件收集指标,然后将指标转发到 Cloud Monitoring。
    • Webhook:设置默认值,拒绝不一致和无效的对象,并对照 Knative serving 资源验证mutates Kubernetes API 调用。Webhook 是一个控制平面组件。
  • 正在运行的 Cloud Service Mesh 在 istio-system 命名空间中安装的组件:

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

Knative serving 组件会在 GKE 控制平面集群进行任何更新时自动更新。如需了解详情,请参阅可用的 GKE 版本

集群资源用量

对于您的集群,Knative serving 的初始安装大约需要 1.5 个虚拟 CPU 和 1 GB 内存。集群中的节点数量不会影响 Knative serving 安装的空间和内存要求。

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

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

创建 Service

展示 Knative serving 服务架构的图
Knative serving 服务架构(点击可放大)

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

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

当用户创建 Knative serving 服务时,会发生以下情况:

  1. Knative serving 服务对象定义:

    1. 有关如何提供修订版本的配置。
    2. 此版服务的不可变修订版本。
    3. 管理指定的流量分配发送到修订版本的路由。
  2. 路由对象创建 VirtualService。VirtualService 对象会配置入站网关和集群本地网关,以将网关流量路由到正确的修订版本。

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

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

请求处理

下图简要展示了在 Google Kubernetes Engine 示例集群上,用户流量通过 Knative serving 数据平面组件的一种可能请求路径:

展示 Knative serving 集群架构的图
Knative serving 集群架构(点击可放大)

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

展示 Knative serving 请求路径的图
Knative serving 请求路径(点击可放大)

对于 Knative serving 请求路径:

  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 将流量发送到用户容器。