3. Knative Eventing 架构概览：核心组件、数据平面与控制平面分离设计
Knative Eventing 采用 控制平面（Control Plane） 与 数据平面（Data Plane） 分离的架构设计。这种设计使得事件路由、订阅管理和实际的事件传输解耦，提升了系统的可扩展性、可观测性和运维灵活性。理解这一架构是掌握 Eventing 版本差异校验的基础。
3.1 核心组件全景
Knative Eventing 由一组 Kubernetes CRD（自定义资源定义）及其对应的控制器组成。下表列出了最核心的组件及其职责：
| 组件（CRD） | 所属平面 | 核心职责 | 版本差异敏感点 |
|---|---|---|---|
| Broker | 控制平面 | 定义事件网格的入口，负责接收事件并将其路由到对应的 Trigger | Broker 类型（如 MT-Channel-Based、Kafka）的 API 版本与配置字段 |
| Trigger | 控制平面 | 定义事件过滤规则（基于 CloudEvents 属性），将 Broker 中的事件转发至特定消费者 | 过滤器语法（exact、prefix、suffix）的版本兼容性 |
| Channel | 数据平面 | 事件缓冲与持久化层，支持多种后端（InMemory、Kafka、NATS） | Channel 的 Spec 版本、交付重试与死信策略字段 |
| Subscription | 控制平面 | 建立 Channel 与 Subscriber（消费者）之间的订阅关系，支持中间处理步骤 | Subscriber URI 解析方式、Reply 策略的版本变化 |
| SinkBinding | 控制平面 | 将事件源（如 Deployment）与事件消费者（如 Service）绑定，注入环境变量 | CloudEvents 版本与绑定协议的演进 |
| Source（如 ApiServerSource、PingSource） | 数据平面 | 生成或导入外部事件到 Eventing 系统 | Source 的 CRD 版本、事件格式与重试机制 |
版本差异校验提示： 在跨版本升级时，Broker 和 Trigger 的 API 版本（v1beta1 → v1）往往涉及默认值变更和字段废弃。Channel 的后端实现（如 InMemoryChannel vs KafkaChannel）在数据平面上的行为差异是容量测试的关键点。
3.2 控制平面与数据平面分离设计
分离设计的核心思想是：控制平面 负责声明式地定义“事件应该去哪里、如何过滤”，而 数据平面 负责实际的事件传输、缓冲和投递。这种分离带来了以下优势：
- 独立演进： 控制平面的 API 版本可以独立于数据平面的实现版本升级。
- 可插拔后端： 数据平面可以替换为不同的消息中间件（如从 InMemory 切换到 Kafka），而控制平面的 Trigger/Subscription 配置无需改动。
- 容量隔离： 数据平面的压力（事件吞吐、积压）不会直接影响控制平面的 API Server 响应。
下图展示了 Knative Eventing 的典型架构，清晰标明了控制平面与数据平面的边界：
3.3 事件流转路径：数据平面与控制平面的交互
一个典型的事件从产生到被消费，会依次经过以下步骤，其中控制平面负责配置，数据平面负责执行：
- 配置阶段（控制平面）： 用户创建
Broker和Trigger，定义事件过滤规则；创建Channel和Subscription，建立订阅关系。 - 事件注入（数据平面）：
Source（如 PingSource）生成事件，或将外部事件（如 HTTP 请求）转换为 CloudEvents 格式，发送到Broker的入口地址。 - 事件路由（数据平面）：
Broker根据Trigger定义的过滤器，将事件分发到对应的Channel或直接投递给Subscriber。 - 事件投递（数据平面）：
Channel负责缓冲事件，Subscription确保事件最终被投递到目标Subscriber（如 Knative Service）。 - 状态反馈（控制平面）： 数据平面的投递状态（成功/失败）通过
Event或Status字段反馈回控制平面，供运维监控。
版本差异校验场景： 在升级过程中，如果控制平面的 Trigger API 版本从 v1beta1 升级到 v1，但数据平面的 Channel 实现（如 InMemoryChannel）未同步升级，可能导致过滤器语义不一致。校验时需要分别验证控制平面配置的正确性和数据平面事件投递的完整性。
3.4 分离设计对版本差异校验的影响
控制平面与数据平面的分离，使得版本差异校验必须从两个维度分别进行：
| 校验维度 | 控制平面关注点 | 数据平面关注点 |
|---|---|---|
| API 版本 | Broker/Trigger/Subscription 的 CRD 版本是否兼容，字段是否废弃或重命名 | Channel/Source 的 CRD 版本是否与后端实现匹配 |
| 行为语义 | 过滤器语法（exact/prefix/suffix）是否按预期工作 | 事件投递重试策略、死信队列行为是否一致 |
| 性能容量 | 控制平面 API 响应时间是否因 CRD 数量增加而劣化 | 数据平面吞吐量、延迟、积压容量是否达标 |
| 可观测性 | 控制平面事件状态（Ready/Error）是否准确反映数据平面状态 | 数据平面指标（事件计数、投递延迟）是否可采集 |
常见陷阱： 在跨版本升级时，控制平面的
Broker 可能默认使用新的 ChannelTemplate 配置，导致数据平面自动创建了不同版本的 Channel。这种隐式变更容易被忽略，但会直接影响事件投递的可靠性和容量表现。