发布时间：2025-12-10 11:32:13 浏览次数：3
目录
序言
1. knative
1.1 发展历程
1.2 特点
2.Serving
2.1 基本介绍
2.2 支持类型
2.3 资源类型
2.3.1 service
2.3.2 Route
2.3.3 Configuration
2.3.4 Revision
2.4 Serving管理能力实现方式
2.4.1 四个 kubernetes Service
2.4.2 二个Deployment
2.4.3 Autoscaler的工作流程
编辑
3总结
3.1 投票
前段时间研究了knative,今天专门来讲一下Knative 的 Serving模块
三言两语，不如细心探索。
本文理论偏多，希望读完此文，能帮助读者对Knative Serving组件有一个初步的了解
文章标记颜色说明：
knative的介绍，在这篇文章，如果想详细了解的话，可以阅读一下
【云原生系列】第二讲：Knative 简介
我们来简单回忆一下Knative是什么。
Knative 发展历程如下
Knative构建在Kubernetes、Istio、Container的基础上，以K8S的CRD形式存在。
如下图所示：
Knative 将kubernetes和istio的复杂度进行抽象和隔离，解决了繁琐的构建，部署，服务治理步骤，并且基于开放标准使得服务变得可移植
Knative 组件包含两个大的领域，分别是Serving和Event。现在讲一下Serving部分。
Serving：即服务
基于Kubernetes的crd提供缩容至零、请求驱动的计算功能。它本质上是无服务器平台的执行和扩展组件。主要有以下特性：
Knative Serving支持容器化的工作负载。
1.FaaS：传统FaaS的函数应用。
通过将传统FaaS平台运行时框架与函数应用一起封装到容器中，实现对FaaS函数应用的支持。
2.单一职责-微服务：满足单一职责原则、可独立部署升级的服务。
这一点上面，Knative很适合用来部署和管理微服务。
3.无状态-应用：主要指传统无状态的单体应用。
虽然Knative不是运行传统应用的**平台，但支持传统无状态应用的部署。
Knative Serving 有四个主要资源：
Knative Serving定义了一套CRD对象。这些对象用于定义和控制Serverless工作负载在集群中的行为，其关系如下：
资源会自动管理工作负载的整个生命周期。
它控制其他对象的创建，以确保应用为服务的每次更新都具有路由，配置和新修订版。
可以将服务定义为始终将流量路由到最新修订版或固定修订版。
创建服务时，它必须创建并拥有与服务同名的配置和路由、更新规范、元数据、标签和元数据。必须将服务注释复制到适当的配置或路由中，如下所示：
同样，服务必须根据其拥有的路由和配置的相应状态更新其状态字段。除一般就绪条件外，服务必须包括ConfigurationReady和RoutesReady条件；也可能存在其他条件。
资源将网络端点映射到一个或多个修订版。可以通过几种方式管理流量，包括部分流量和命名路由。
资源维护部署的所需状态。
它在代码和配置之间提供了清晰的分隔，并遵循了十二要素应用程序方法。
修改配置会创建一个新修订。
十二要素应用程序方法
为了云原生应用程序而新增加3个因素：
资源是对工作负载进行的每次修改的代码和配置的时间点快照。
修订是不可变的对象，可以保留很长时间。也可以根据传入流量自动缩放实例数。
有关更多信息，请参见配置自动缩放器。
Knative Serving组件包含k8s的
构成了Serving的整体管理能力。
1.autoscaler：接收请求指标数据并调整需要的Pod数量以处理流量负载。
2.activator：负责为不活跃状态的修订版接收并缓存请求，同时报告指标数据给autoscaler。在autoscaler扩展修订版之后，它还负责将请求重试到修订版
3.controller：协调所有公共Knative对象，自动扩展CRD。
当用户请求一个Knative service给Kubernetes API，controller将创建对应配置和路由，并将配置转换为revision，同时将revision转化为deployment和KPA。
4.webhook：拦截所有Kubernetes API调用以及所有CRD的插入和更新操作，用来设置默认值，拒绝不一致和无效的对象，验证和修改Kubernetes API调用。
1.networking-certmanager：协调集群的ingrese为证书管理对象。
2.networking-istio：协调集群的ingress为Istio的虚拟服务。
Serverless的重要特点之一就是事件驱动计算。
当没有请求时，系统不会分配相应的资源给服务。
因此，Knative Serving支持从零开始扩容，也支持缩容到零。
在初始状态下，修订版的副本是不存在的。客户端发起请求时，系统要完成工作负载的激活过程。
Knative的扩缩容的流程如下图所示：
初次请求：
1.请求通过入口网关转发给Activator
2.Activator负责为不活跃状态的修订版接收并缓存请求，同时报告指标数据给Autoscaler；3.Autoscaler会创建修订版的Deployment对象；Deployment对象根据Autoscaler设定的扩展副本数创建相应数量的Pod副本。
一旦Pod副本的状态变为Ready，Activator会将缓存的客户端请求转发给对应的Pod副本。
4.Gateway然后会将新的请求直接转发给相应的Pod副本，不再转发给Activator。
缩容到零的流程：
当一定时间周期内没有请求时，Autoscaler会将Pod副本数设置为零，回收Pod所占资源。
同时Gateway会将后续请求路由到Activator，如果后续请求出现可以触发初次请求流程。
持续请求流程：
修订版副本中的Queue Proxy容器会不断报告指标数据给Autoscaler，Autoscaler会根据当前的指标数据情况以及扩缩容算法不断调整修订版的副本数量。
Queue Proxy：
Knative服务对应的Pod里有两个容器，分别是
User Container：为Knative服务中定义的业务容器，包含应用程序及其依赖的运行环境。Queue Proxy：是系统容器，以Sidecar方式存在。
Knative Serving为每个Pod注入Queue代理容器 (queue-proxy)。
queue-proxy容器负责向Autoscaler报告用户容器流量指标。
Autoscaler接收到这些指标之后，会根据流量指标及相应的算法调整Deployment的Pod副本数量，从而实现自动扩缩容。
扩缩容算法：
Autoscaler 默认基于Pod接收到的并发请求数扩缩容资源。
Pod并发请求数的目标值（target）默认为100。
计算公式是：Pod数=并发请求总数/Pod并发请求数的目标值。
如果Knative服务中配置并发请求数的目标值为10，那么如果加载了50个并发请求到Knative服务，Autoscaler 就会创建了5个 Pod。
Autoscaler实现了两种模式的缩放算法：
稳定模式：
在稳定模式下，Autoscaler自动调整Deployment的大小，以实现每个Pod所需的平均并发数。
Pod的并发数是根据60秒窗口期内接收到的所有数据请求的平均数来计算得出。
恐慌模式：
1.Autoscaler计算60秒窗口期内的平均并发数，系统需要60秒内稳定在所需的并发级别。
2.同时，Autoscaler 也会计算6秒的窗口期
当6秒窗口期内达到了目标并发数的2倍，则会进入恐慌模式。
在恐慌模式下，Autoscaler将在时间更短、对请求更敏感的紧急窗口上工作。一旦紧急情况持续 60 秒，Autoscaler 将返回初始的 60 秒稳定窗口。
Knative Serving组件是Knative的核心组件，它完成了一个Serverless计算平台最重要的能力，即服务的部署与弹性伸缩。
Knative Service资源对象集成了配置管理、版本管理、流量控制以及扩缩容控制，极大地简化了Serverless的服务管理。
容器的主要限制：
若表达不当的地方，欢迎各位大佬评论区留言讨论~
免责声明：本站内容（文字信息+图片素材）来源于互联网公开数据整理或转载，仅用于学习参考，如有侵权问题，请及时联系本站删除，我们将在5个工作日内处理。联系邮箱：303555158#qq.com（把#换成@）
微信便捷交流