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 命名空间中安装的组件：

  • 激活程序：当 Pod 缩减至零或由于发送到修订版本的请求过多而过载时，激活程序会暂时将请求加入队列，并向自动扩缩器发送指标以启动更多 Pod。自动扩缩器根据报告的指标和可用 Pod 扩缩修订版本后，激活程序会将队列中的请求转发到该修订版本。激活程序是一个数据平面组件；数据平面组件管理转发用户流量的所有功能和进程。
  • 自动扩缩器：汇总并处理来自激活程序和队列代理边车容器（数据平面中强制执行请求并发限制的组件）的指标。然后，自动扩缩器会计算观察到的针对修订版本的并发，并根据所需的 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 通过定义一组自定义资源定义 (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 请求路径：

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