Knative的服务管理组件Serving

Knative的服务管理组件Serving是管理应用服务的理想选择，它通过自动缩容为零和基于HTTP负载自动扩展的方式简化了部署流程。Knative平台可管理应用服务的部署、版本、网络、扩缩容。

Knative Serving通过HTTP URL的方式来暴露服务，有许多默认的安全设置。在特定的使用场景下，我们需要调整这些默认值，或者调整服务版本之间的流量分配来满足需求。由于Knative Serving具有自动缩容为零的能力，因此称其为Serverless。

Serving的架构设计

Knative Serving建立在Kubernetes和Istio的基础上，支持Serverless应用和函数的部署与管理。Knative Serving易于上手并且可扩展，以便支持高级使用场景。

Knative Serving提供中间件原语来实现以下能力。

·快速部署无服务器容器。

·自动扩缩容机制，支持缩容到零。

·基于Istio组件的服务路由和网络编程。

·部署代码的时间点快照以及配置管理。

Knative Serving支持以下容器化的工作负载。

·Function：传统FaaS的函数应用。通过将传统FaaS平台运行时框架与函数应用一起封装到容器中，实现对FaaS函数应用的支持。

·微服务：满足单一职责原则、可独立部署升级的服务。Knative非常适合用来部署和管理微服务。

·传统应用：主要指传统无状态的单体应用。虽然Knative不是运行传统应用的最佳平台，但支持传统无状态应用的部署。

Knative Serving定义了一套CRD对象。这些对象用于定义和管理Serverless工作负载在集群中的行为，如下所示。

Knative Serving对象模型 

1）服务（Service）：service.serving.knative.dev资源自动管理用户工作负载的整个生命周期。它控制路由和配置对象的创建，在服务更新时确保应用有对应的服务路由、配置和新的修订版。服务可以被定义为总是把流量路由到最新的修订版或特定修订版。

2）路由（Route）：route.serving.knative.dev资源用于映射一个网络端点到一个或更多修订版。你可以用多种方式来管理流量，包括分流和命名路由。

3）配置（configuration）：configuration.serving.knative.dev资源维护了部署应用的最终状态。它遵循云原生应用12要素原则，提供了代码和配置分离的机制。每次修改配置会创建一个新的修订版。

4）修订版（Revision）：revision.serving.knative.dev资源是在每次变更工作负载时生成的代码和配置的时间点快照。修订版是不可变对象。系统会保留有用的修订版本，删除不再使用的修订版。修订版对应的Pod实例数量会根据流量的大小自动进行伸缩。

 Knative相关的Kubernetes Service

Knative Serving组件包含4个Kubernetes Service和2个Deployment，构成了Serving的整体管理能力。

1）Activator（Service）：负责为不活跃状态的修订版接收并缓存请求，同时报告指标数据给Autoscaler。在Autoscaler扩展修订版之后，它还负责将请求重试到修订版。

2）Autoscaler（Service）：接收请求指标数据并调整需要的Pod数量以处理流量负载。

3）Controller（Service）：协调所有公共Knative对象，自动扩展CRD。当用户请求一个Knative Service给Kubernetes API时，Controller将创建对应配置和路由，并将配置转换为revision，同时将revision转化为Deployment和KPA。

4）Webhook（Service）：拦截所有Kubernetes API调用以及所有CRD的插入和更新操作，用来设置默认值，拒绝不一致和无效的对象，验证和修改Kubernetes API调用。

5）networking-certmanager（Deployment）：协调集群的Ingrese为证书管理对象。

6）networking-istio（Deployment）：协调集群的Ingress为Istio的虚拟服务。

Autoscaler的工作流程

Serverless的重要特点之一就是请求驱动计算。当没有请求时，系统不会分配相应的资源给服务。Knative Serving支持从零开始扩容，也支持缩容到零。在初始状态下，修订版的副本是不存在的。客户端发起请求时，系统要完成工作负载的激活。

1.Knative的扩缩容流程

Knative的扩缩容流程如下所示。

Knative自动扩缩容的架构图 

1）初次请求流程：客户端请求通过入口网关转发给Activator，然后由Activator为不活跃状态的修订版接收并缓存请求，同时报告指标数据给Autoscaler，接着由Autoscaler创建修订版的Deployment对象，接着由Deployment对象根据Autoscaler设定的扩展副本数创建相应数量的Pod副本。一旦Pod副本的状态变为Ready，Activator会将缓存的客户端请求转发给对应的Pod副本。Gateway然后会将新的请求直接转发给相应的Pod副本，不再转发给Activator。

2）持续请求流程：修订版副本中的Queue Proxy容器会不断报告指标数据给Autoscaler，由Autoscaler根据当前的指标数据情况不断调整修订版的副本数量。

3）缩容到零的流程：当一定时间周期内没有请求时，Autoscaler会将Pod副本数设置为零，回收Pod所占资源。同时，Gateway会将后续请求路由到Activator，如果后续请求出现，则触发初次请求流程。

2.扩缩容算法

Autoscaler默认基于Pod接收到的并发请求数扩缩容资源。Pod并发请求数的目标值（target）默认为100。计算公式是：Pod数=并发请求总数/Pod并发请求数的目标值。如果Knative服务中配置并发请求数的目标值为10，且加载了50个并发请求到Knative服务，Autoscaler就会创建5个Pod。

为了快速响应负载的变化，同时避免过度响应负载变化导致频繁创建销毁Pod，Autoscaler实现了两种模式的缩放算法：稳定模式（Stable）和恐慌模式（Panic），如下所示。

Autoscaler的两种工作模式 

1）稳定模式：在稳定模式下，Autoscaler自动调整Deployment的大小，以实现每个Pod所需的平均并发数。Pod的并发数是根据60秒窗口期内接收到的所有数据请求的平均数计算得出的。

2）恐慌模式：Autoscaler计算60秒窗口期内的平均并发数，系统需要在60秒内稳定在所需的并发级别。与此同时，Autoscaler也会计算6秒的窗口期内的平均并发数，一旦该窗口期内平均并发数达到目标并发数的2倍，则会进入恐慌模式。在恐慌模式下，Autoscaler将在时间更短、对请求更敏感的紧急窗口工作。紧急情况持续60秒后，Autoscaler将返回初始的60秒稳定窗口。

Queue Proxy

Knative服务对应的Pod里有两个容器，分别是User Container和Queue Proxy。User Container为Knative服务中定义的业务容器，包含应用程序及其依赖的运行环境。Queue Proxy是系统容器，以Sidecar方式存在。

Knative Serving为每个Pod注入Queue代理容器（Queue Proxy）。该容器负责向Autoscaler报告用户容器流量指标。Autoscaler接收到这些指标之后，会根据流量指标及相应的算法调整Deployment的Pod副本数量，从而实现自动扩缩容。

Queue Proxy各端口的定义如下。

·8012：Queue Proxy代理的HTTP端口，访问应用流量的入口。

·8013：HTTP2端口，用于gRPC流量的转发，未使用。

·8022：Queue Proxy管理端口，如健康检查等。

·9090：Queue Proxy容器的监控端口，数据由Autoscaler采集，用于实现基于请求的自动扩缩容。

·9091：Queue Proxy采集到的应用监控指标（请求数、响应时长等），由Prometheus采集。

以HTTP1请求为例，介绍Queue Proxy的工作原理。

业务流量首先进入Istio Gateway，然后被转发到Queue Proxy的8012端口，然后由Queue Proxy 8012端口把请求转发到User Container的监听端口，至此一个业务请求的服务就完成了，如下所示。

Queue Proxy的工作原理