2. Knative 核心架构：Serving 与 Eventing 组件、Revision 与 Route 模型、自动扩缩容机制

Knative 建立在 Kubernetes 之上，通过 Serving 和 Eventing 两大核心组件，为无服务器工作负载提供部署、路由、自动扩缩容以及事件驱动能力。理解这两个组件的协作关系，是掌握流量镜像与调试的前提。

2.1 Knative Serving：无服务器工作负载的运行时引擎

Knative Serving 负责管理容器化应用的部署、路由和自动扩缩容。它通过几个关键的自定义资源（CRD）来抽象无服务器应用的完整生命周期。

2.1.1 核心资源模型

2.1.2 Revision 与 Route 模型：流量管理的基石

Revision 和 Route 构成了 Knative Serving 的流量路由模型。Revision 是不可变的，保证了每次部署的可追溯性；Route 则提供了灵活的流量分发能力。

2.2 Knative Eventing：事件驱动架构的核心

Knative Eventing 提供了一套完整的事件管理框架，用于连接事件生产者（Broker）和事件消费者（Trigger、Sink）。它解耦了事件的产生与处理，使得服务可以响应外部事件（如 Kafka 消息、GitHub Webhook）或内部事件（如服务状态变更）。

2.2.1 核心组件与事件流

• Broker：事件网格的入口，负责接收和转发事件。每个 Broker 对应一个事件通道（如 InMemoryChannel、KafkaChannel）。
• Trigger：定义事件过滤规则（基于事件类型、来源等），将匹配的事件从 Broker 转发到特定的 Sink（如 Knative Service、Kubernetes Service）。
• Sink：事件的最终消费者，通常是 Knative Service 或任何实现了 Addressable 接口的资源。
• Source：事件的生产者，如 ApiServerSource、PingSource、KafkaSource。

2.3 自动扩缩容机制：KPA（Knative Pod Autoscaler）

Knative Serving 内置了基于请求驱动的自动扩缩容机制，核心是 KPA（Knative Pod Autoscaler）。与传统的 CPU/内存指标不同，KPA 根据并发请求数（Concurrency）或 RPS（每秒请求数）进行扩缩容，实现从零到 N 的弹性伸缩。

2.3.1 关键参数与行为

2.3.2 扩缩容流程

1. 请求到达：请求通过 Route 进入 Revision 的 Pod。
2. 指标采集：Queue-Proxy（每个 Pod 内的 Sidecar 代理）采集并发请求数。
3. KPA 决策：KPA 根据采集到的指标与 target 值对比，计算期望的 Pod 副本数。
4. 调整副本：KPA 通过调整 Deployment 的 replicas 字段来扩缩容。
5. 缩容到零：当无请求时，KPA 在 scale-to-zero-grace-period 后将副本数降为 0，释放资源。