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 核心概念关系图

下图展示了事件从产生到消费的完整路径,以及各组件在控制面调度中的位置:

Knative Eventing 核心概念关系图 Knative Eventing 核心概念与事件流 事件源 Event Source 代理 Broker 通道 Channel 触发器 Trigger 订阅 Subscription 接收者 Sink (Service/URI) 注入事件 路由 持久化 订阅 投递事件 说明: Broker 模式使用 Trigger 进行过滤路由;Channel 模式使用 Subscription 进行直接订阅。两者可混合使用。 控制面调度关注 Broker/Channel 的资源配额、背压与事件投递延迟。

2.7 两种事件路由模式对比

Knative Eventing 提供两种互补的路由模式,理解其差异有助于在控制面调度中做出正确选择:

维度 Broker + Trigger 模式 Channel + Subscription 模式
抽象层级 高级,面向事件网格 低级,面向消息通道
过滤能力 内置 CloudEvents 属性过滤 需自定义中间件或 Subscriber 实现
多订阅者 一个 Broker 支持多个 Trigger 一个 Channel 支持多个 Subscription
控制面复杂度 较低,Broker 自动管理底层 Channel 较高,需手动管理 Channel 与 Subscription
调度推荐 标准控制面事件路由 需要精细控制事件流时使用
工程实践:在控制面资源调度系统中,推荐以 Broker + Trigger 模式作为主要事件路由方式,降低运维复杂度;仅在需要多级事件处理管道或严格顺序保证时,引入 Channel + Subscription 模式。