🛻Knative Architecture

Serving

关键组件

• Activator核心作用是处理缩容至零（scale-to-zero） 的 Knative Service 请求：接收并排队这类请求，同时与 Autoscaler 通信触发服务扩缩容，待服务启动后转发排队请求；也可作为请求缓冲器，应对流量突发场景。

• Autoscaler负责 Knative Service 的自动扩缩容，基于服务配置（如并发阈值）、实时监控指标（如请求数、CPU 使用率）和实际入流量，动态调整 Service 对应的 Pod 副本数量，实现按需分配资源。

• Controller属于控制平面核心组件，负责管理集群内 Knative 资源的全生命周期：监听 Knative Service、Route、Revision 等资源的状态变化，协调依赖资源的创建与销毁，确保资源状态与用户定义的期望状态一致。

• Queue-Proxy以边车容器（Sidecar） 形式部署在 Knative Service 的每个 Pod 中，核心功能包括：收集 Pod 级别的请求指标（供 Autoscaler 决策）；转发请求到用户业务容器时，强制执行预设的并发限制；必要时可作为本地请求队列，缓冲突发流量。

• Webhooks属于控制平面组件，包含多个验证和变异 Webhook，作用是在 Knative 资源（如 Service、Route）被创建或更新时，对资源配置进行合法性校验，或自动注入必要的配置（如默认标签、注解），确保资源符合 Knative 运行规范。

组件之间的关系

控制平面与数据平面的协作

• Controller 负责资源的状态管理，当用户创建 Knative Service 后，Controller 会生成对应的 Revision 和网络路由规则，并触发 Queue-Proxy 随业务容器一同部署。

• Webhooks 作为 Controller 的前置环节，在资源提交至集群时完成校验和变异，保证 Controller 处理的资源配置合法有效。

流量处理与扩缩容联动

• 当 Service 缩容至零时，外部请求会被路由至 Activator，Activator 排队请求并通知 Autoscaler 进行扩容。

• Autoscaler 基于 Queue-Proxy 收集的 Pod 指标和 Activator 上报的排队请求数，计算需要的 Pod 副本数，通知 Controller 完成 Pod 调度。

• Pod 启动后，Queue-Proxy 接管本 Pod 的请求转发和并发控制，Activator 则将排队的请求转发至新启动的 Pod，后续请求直接路由至 Pod 内的 Queue-Proxy。

指标与决策的闭环

网络路由部分

Knative Service创建时有哪些资源我们需要关注？

Queue Proxy

• 单pod内Sidecar模式

• 业务流量、管理接口、指标采集三个平面节藕

• Queue proxy是knative中运行单位（一个serverless服务）唯一对外入口

AutoScaler

autoscaler scale deployment replica 源码阅读

Activator

activator 流量暂存能力 源码阅读

流量的分发逻辑

流量暂存的实现逻辑

• 一个goroutine 2KB+

• 每个等待请求: 约 10-50 KB（取决于请求大小）

• Channel: 几乎不占内存（只存储信号）

• 队列深度 10000: 最多约 100-500 MB

如果流量一直积压会怎么样？会一直积压在内存中吗？

整体的网络流转流程

Ref

• https://knative.dev/docs/serving/architecture/

• https://github.com/knative/serving

Eventing TODO