2. Knative 核心概念：Serving 与 Eventing 组件介绍
Knative 在 Kubernetes 之上抽象出两大核心组件：Serving（无服务器工作负载管理）与 Eventing（事件驱动基础设施）。理解这两个组件的资源模型是进行容量规划的前提。
2.1 Knative Serving：自动扩缩容与流量管理
Serving 负责将容器化应用以无服务器方式运行，核心能力包括：
- 自动扩缩容至零：无请求时 Pod 数降为 0，有请求时快速启动。
- 流量灰度与版本管理：支持蓝绿部署、金丝雀发布。
- 内置监控与自动伸缩：基于并发数（Concurrency）或 RPS 自动调整副本数。
2.2 Serving 资源模型：Revision、Configuration、Route、Service
Serving 定义了四个核心 CRD（自定义资源），它们之间存在明确的层级关系：
| 资源 | 缩写 | 职责 | 关键属性 |
|---|---|---|---|
| Revision | rev | 不可变的快照，记录代码 + 配置的某个版本 | 容器镜像、环境变量、资源 requests/limits、并发数限制 |
| Configuration | config | 管理 Revision 的期望状态，每次更新生成新 Revision | 最新就绪 Revision 名称、当前 Revision 列表 |
| Route | route | 流量分发规则，将请求路由到指定 Revision | 流量百分比分配、URL 映射、标签选择 |
| Service | ksvc | 顶层抽象，自动管理 Configuration 和 Route | 对外暴露 URL、自动创建 Revision 和流量规则 |
容量规划要点： Revision 的
containerConcurrency（硬限制）和 requestsPerSecond（软限制）直接影响扩缩容阈值，是规划最小/最大副本数的核心参数。
2.3 Knative Eventing：事件驱动解耦
Eventing 提供事件生产、中转、消费的完整基础设施，核心概念包括：
- Event Source：事件源，如 Kafka、S3、GitHub Webhook、定时器。
- Broker：事件代理，负责接收事件并路由到对应的 Trigger。
- Trigger：事件触发器，定义过滤规则（事件类型、来源）并将事件转发给特定 Service。
- Channel & Subscription：底层事件通道与订阅机制，支持点对点或发布/订阅模式。
容量规划提示： Eventing 的 Broker 和 Channel 通常需要预留一定的缓冲容量（如 Kafka 分区数、内存队列大小），避免事件积压导致背压（Backpressure）影响 Serving 层扩缩容决策。
2.4 Eventing 典型事件流
一个完整的事件驱动流程如下：
- 事件源（如 KafkaSource）从外部系统拉取事件。
- 事件被发送到 Broker（默认使用 InMemoryChannel 或 KafkaChannel）。
- Trigger 根据事件类型/来源过滤，将匹配的事件转发到对应的 Knative Service。
- Knative Service 的 Revision 接收事件并处理，处理过程中可能触发自动扩缩容。
2.5 Serving 与 Eventing 的协同关系
在容量规划实践中，Serving 和 Eventing 并非孤立工作：
- Eventing 的 事件速率 直接影响 Serving 的扩缩容频率和幅度。
- Serving 的 冷启动延迟 会影响事件处理的最大吞吐量。
- Eventing 的 背压机制（如 Kafka 消费者滞后）会反向调节事件注入速率，形成闭环。
常见误区： 只关注 Serving 的扩缩容策略而忽略 Eventing 的事件缓冲能力，可能导致突发流量下事件丢失或 Broker 内存溢出。容量规划必须同时考虑两个组件的资源边界。
2.6 核心资源模型对比总结
| 维度 | Serving | Eventing |
|---|---|---|
| 核心资源 | Service, Configuration, Route, Revision | Broker, Trigger, Channel, Subscription, Source |
| 扩缩容依据 | 并发数、RPS、CPU 利用率 | 事件积压量、消费者滞后 |
| 状态管理 | 无状态为主，Revision 不可变 | 有状态（Channel 需持久化） |
| 容量规划关注点 | 最小/最大副本数、并发限制、冷启动资源 | 缓冲区大小、分区数、事件 TTL |