当前位置：首页 > news >正文

详解Knative的服务管理组件（Serving）

news 来源：原创 2024/5/2 17:27:56

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

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

01 Serving的架构设计

Knative Serving建立在Kubernetes基础之上，支持Serverless应用和函数的部署与管理。Knative Serving提供了以下中间件原语。

快速部署无服务容器。
自动扩缩容机制，支持缩容到零。
基于Istio组件的服务路由和网络编程。
部署代码的时间点快照以及配置管理。

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

Function：传统FaaS的函数应用。通过将传统FaaS平台运行时框架与函数应用一起封装到容器中，实现对FaaS函数应用的支持。
微服务：满足单一职责原则、可独立部署升级的服务。Knative非常适合用来部署和管理微服务。
传统应用：主要指传统无状态的单体应用。虽然Knative不是运行传统应用的最佳平台，但支持传统无状态应用的部署。

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

图1 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实例数量会根据流量的大小自动进行伸缩。

02 Serving相关的Kubernetes Services

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

activator（Service）：负责为不活跃状态的修订版接收并缓存请求，同时报告指标数据给autoscaler。在autoscaler扩展修订版之后，它还负责将请求重试到修订版
autoscaler（Service）：接收请求指标数据并调整需要的Pod数量以处理流量负载。
controller（Service）：协调所有公共Knative对象，自动扩展CRD。当用户请求一个Knative service给Kubernetes API，controller将创建对应配置和路由，并将配置转换为revision，同时将revision转化为deployment和KPA。
webhook（Service）：拦截所有Kubernetes API调用以及所有CRD的插入和更新操作，用来设置默认值，拒绝不一致和无效的对象，验证和修改Kubernetes API调用。
networking-certmanager（Deployment）：协调集群的ingrese为证书管理对象。
networking-istio（Deployment）：协调集群的ingress为Istio的虚拟服务。

03 Autoscaler的工作流程

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

Knative的扩缩容的流程如图2所示。

图2 Knative自动扩缩容的架构图

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

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

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

04 扩缩容算法

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

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

图3 Autoscaler的两种工作模式

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

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

05 Queue Proxy

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

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

06 总结

Knative Serving组件是Knative的核心组件，它完成了一个Serverless计算平台最重要的能力，即服务的部署与弹性伸缩。Knative Service资源对象集成了配置管理、版本管理、流量控制以及扩缩容控制，极大地简化了Serverless的服务管理。

本文摘编于机械工业出版社出版的图书《Knative实战:基于Kubernetes的无服务器架构实践》。

关于作者：

李志伟 某网云原生实验室负责人，容器云领域专家。在Kubernetes、Istio、Serverless、DevOps工具等领域有深入的研究和实践。热心于云原生技术的应用与推广，曾荣获“K8sMeetup中国社区”最受欢迎讲师奖项。

游杨某网云原生实验室高级运维开发工程师。先后参与Kubernetes和Knative项目的落地与实施工作，拥有丰富的容器平台实践经验，聚焦于Kubernetes、Serverless、CI/CD技术领域。