2. 核心概念与术语:事件源、触发器、代理、通道、订阅详解
在 Knative Eventing 体系中,事件的生产、路由、过滤与投递由五个核心抽象协作完成。理解这些概念是掌握控制面资源调度的基础。本章逐一拆解每个组件的职责、生命周期与典型交互模式。
2.1 事件源(Event Source)
事件源是产生外部事件的实体,它将来自不同后端(如 Kafka、GitHub、S3、自定义应用)的事件转换为 CloudEvents 标准格式,并注入 Knative Eventing 系统。
- 职责:监听外部系统变化,生成 CloudEvent 并发送至目标(通常是 Broker 或 Channel)。
- 生命周期:通过
ApiServerSource、PingSource、KafkaSource等 CRD 定义,由 Reconciler 控制其运行状态。 - 控制面调度关注点:事件源的副本数、网络连通性、重试策略直接影响事件注入的可靠性与延迟。
关键指标:事件源每秒注入事件数(EPS)、事件源到 Broker 的投递成功率。
2.2 代理(Broker)
Broker 是事件网格的“中心枢纽”,负责接收来自事件源的事件,并根据 Trigger 规则进行过滤与路由。每个 Broker 对应一个独立的命名空间级事件平面。
| 属性 | 说明 |
|---|---|
| 默认实现 | 基于 InMemoryChannel 的 MT-Channel-Broker(多租户) |
| 生产推荐 | 基于 KafkaChannel 的 KafkaBroker,提供持久化与分区能力 |
| 控制面资源 | Broker 本身为 CRD,其 Reconciler 会创建对应的 Channel、Deployment、Service |
| 调度影响 | Broker 的副本数、背压策略、事件缓冲区大小直接影响吞吐与稳定性 |
实践建议:在控制面资源调度场景中,建议为每个关键业务域创建独立 Broker,避免事件相互干扰;同时为 Broker 配置资源配额(CPU/Memory)与 HPA,应对突发流量。
2.3 触发器(Trigger)
Trigger 定义了事件从 Broker 到特定 Sink(如 Knative Service、Kubernetes Service、URI)的订阅规则。它包含事件过滤条件(基于 CloudEvents 属性)和投递目标。
- 过滤机制:支持按事件类型(type)、来源(source)、扩展属性(extension)进行精确或前缀匹配。
- 投递语义:默认至少一次(at-least-once),可通过重试策略与死信队列(DLQ)增强可靠性。
- 控制面调度关联:Trigger 的创建会触发 Broker 内部路由表的更新;大量 Trigger 的并发变更可能造成 Broker 控制面压力。
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
name: resource-scaler-trigger
spec:
broker: default
filter:
attributes:
type: com.example.scale.request
source: /control-plane/scheduler
subscriber:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: resource-scaler
2.4 通道(Channel)
Channel 是事件缓冲与传输的底层抽象,负责在事件源与订阅者之间提供临时存储与分发能力。它是 Broker 和 Subscription 的底层基础设施。
| 通道类型 | 持久化 | 顺序保证 | 适用场景 |
|---|---|---|---|
| InMemoryChannel | 无 | 尽力 | 开发测试、低吞吐场景 |
| KafkaChannel | 有(Kafka 日志) | 分区内严格有序 | 生产环境、高吞吐、需回溯 |
| NATSChannel | 有(NATS JetStream) | 按主题有序 | 低延迟、云原生消息 |
调度风险:InMemoryChannel 在 Pod 重启时丢失事件,不适合控制面调度场景。生产环境必须使用 KafkaChannel 或 NATSChannel 等持久化通道。
2.5 订阅(Subscription)
Subscription 是 Channel 模式下的核心路由原语,它将 Channel 与一个或多个 Subscriber(接收者)连接起来,并可配置中间处理步骤(如转换、过滤)。
- 组成:Channel 引用 + Subscriber 引用 + 可选的 Reply 策略。
- 与 Trigger 的关系:Trigger 是 Broker 模式下的高级抽象,底层依赖 Subscription 实现;Subscription 更底层、更灵活。
- 控制面调度影响:Subscription 的变更会触发 Channel 的 Dispatcher 组件重新加载路由表,影响事件投递路径。
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
name: scale-event-sub
spec:
channel:
apiVersion: messaging.knative.dev/v1
kind: Channel
name: scale-channel
subscriber:
uri: http://resource-scaler.default.svc.cluster.local
reply:
uri: http://result-collector.default.svc.cluster.local
2.6 核心概念关系图
下图展示了事件从产生到消费的完整路径,以及各组件在控制面调度中的位置:
2.7 两种事件路由模式对比
Knative Eventing 提供两种互补的路由模式,理解其差异有助于在控制面调度中做出正确选择:
| 维度 | Broker + Trigger 模式 | Channel + Subscription 模式 |
|---|---|---|
| 抽象层级 | 高级,面向事件网格 | 低级,面向消息通道 |
| 过滤能力 | 内置 CloudEvents 属性过滤 | 需自定义中间件或 Subscriber 实现 |
| 多订阅者 | 一个 Broker 支持多个 Trigger | 一个 Channel 支持多个 Subscription |
| 控制面复杂度 | 较低,Broker 自动管理底层 Channel | 较高,需手动管理 Channel 与 Subscription |
| 调度推荐 | 标准控制面事件路由 | 需要精细控制事件流时使用 |
工程实践:在控制面资源调度系统中,推荐以 Broker + Trigger 模式作为主要事件路由方式,降低运维复杂度;仅在需要多级事件处理管道或严格顺序保证时,引入 Channel + Subscription 模式。