Knative Eventing Broker 类型全解析：MTChannelBasedBroker、Kafka Broker 与 RabbitMQ Broker 的选型与实践-平芜编程栈

文档
教程
云原生

【免费下载链接】docs

User documentation for Knative components.

项目地址：https://gitcode.com/gh_mirrors/docs1/docs

Knative Eventing 通过Broker与Trigger两个核心 API 构建事件网格（Event Mesh），而 Broker 的具体实现可以有多种类型。本文以仓库中可用 Broker 类型参考文档为骨架，系统讲解随 Knative Eventing 默认发布的Channel-based Broker（MTChannelBasedBroker），以及社区与厂商提供的Knative Broker for Apache Kafka与RabbitMQ Broker三种实现：包括各自的架构定位、安装前置条件、创建方式、核心配置项与安全、投递语义等高阶特性，并给出选型建议。读完本文，你将能够根据业务场景在三种 Broker 类型中做出选择，并独立完成创建、配置与故障排查。

Broker 与事件网格：先理解 Broker 的定位

在深入具体类型之前，先明确 Broker 在 Knative Eventing 中的角色。Broker 是 Kubernetes 自定义资源，用于定义一个收集事件池的事件网格（Event Mesh）：它为事件提供可发现的入口端点，事件生产者通过 HTTP POST 即可将事件发送到 Broker；而事件的分发则由Trigger完成——Trigger 按 CloudEvents 属性过滤事件并将匹配的事件投递给指定的 Sink（如 Knative Service）。从Brokers 概览文档可以看到，事件投递的具体机制属于实现细节，取决于配置的 Broker 类（Broker class），而 Broker + Trigger 的组合把事件路由细节从生产者和消费者中抽象出来。

Knative Eventing 支持三种主要 Broker 类型：

Broker 类	底层技术	定位
`MTChannelBasedBroker`	Knative Channel	随 Eventing 默认发布，基于 Channel 做事件路由
`Kafka`/`KafkaNamespaced`	Apache Kafka	原生面向 Kafka，减少网络跳数，深度集成 Kafka
`RabbitMQBroker`	RabbitMQ	由社区提供，基于 RabbitMQ 实现

社区与厂商的替代实现只要遵守 Broker 规范（特别是 Broker 生命周期相关的控制面规范），就欢迎加入 Knative Eventing 生态。下面逐一展开。

Channel-based Broker（MTChannelBasedBroker）

工作原理与适用场景

MTChannelBasedBroker使用 Knative Channel 作为事件路由的底层机制，随 Knative Eventing 默认发布，也是默认的 Broker 类。它的事件流如下：事件源将事件发送给 Broker，Broker 把事件转发到底层 Channel，Channel 再通过 Subscriptions 将事件扇出（fan-out）到多个 Sink。

需要明确的是，官方文档建议用户优先选择原生 Broker 实现（如 Knative Broker for Apache Kafka 或 RabbitMQ Broker）而非MTChannelBasedBroker+ Channel 的组合，因为原生实现通常更高效，例如能减少网络跳数。

前置条件

使用MTChannelBasedBroker有两个前置条件：

已安装 Knative Eventing。
已安装一种 Channel 实现。由于MTChannelBasedBroker基于 Channel 构建，必须安装 Channel 实现才能工作。Knative Eventing 可用的 Channel 列表（非穷举）见 channels-crds.md，主要包括：
- InMemoryChannel（Stable）：尽力而为型 Channel，不应在生产环境使用，适合开发调试；
- KafkaChannel（Beta）：由 Apache Kafka topic 支撑；
- NatssChannel（Alpha）：由 NATS Streaming 支撑。

例如，安装 InMemoryChannel 的命令如下（使用 Knative Eventing 发布物中的in-memory-channel.yaml）：

kubectl apply -f in-memory-channel.yaml

创建 MTChannelBasedBroker

你可以用knCLI 或kubectl应用 YAML 两种方式创建：

方式一：kn CLI

kn broker create <broker-name> --class MTChannelBasedBroker

其中<broker-name>是 Broker 的名称。

方式二：kubectl 应用 YAML

apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: MTChannelBasedBroker name: <broker-name>

应用：

kubectl apply -f <filename>.yaml

注意：Broker 类是通过eventing.knative.dev/broker.class注解指定的，且该注解不可变——Broker 创建后无法再更新，因此创建前要确定 Broker 类。若省略该注解，则使用config-br-defaultsConfigMap 中定义的默认 Broker 类（详见下文"默认配置"）。更完整的创建流程（含验证命令kn broker list、kubectl get broker及 READY 状态判断）可参考 create-broker.md。

配置 Channel-based Broker

MTChannelBasedBroker的配置可以做到 Broker 个体级别，也可以在集群或命名空间级别设置默认值。

Broker 特定配置：在spec.config中引用一个 ConfigMap，即可为单个 Broker 定制配置：

apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: MTChannelBasedBroker name: default spec: # Configuration specific to this broker. config: apiVersion: v1 kind: ConfigMap name: my-broker-specific-configuration namespace: default

被引用的 ConfigMap 必须包含channel-template-spec字段，它定义该 Broker 底层的 Channel 实现及 Channel 专属配置。例如使用 InMemoryChannel：

apiVersion: v1 kind: ConfigMap metadata: name: my-broker-specific-configuration namespace: default data: channel-template-spec: | apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel

若希望底层使用 KafkaChannel，可参考 Kafka Channel 配置文档中的示例：

apiVersion: v1 kind: ConfigMap metadata: name: kafka-channel namespace: knative-eventing data: channel-template-spec: | apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel spec: numPartitions: 3 replicationFactor: 1

其中numPartitions与replicationFactor是 KafkaChannel 专属参数：前者控制 topic 分区数（直接影响并行消费能力），后者控制消息副本因子（必须小于等于集群中的 Kafka broker 节点数）。

默认配置（config-br-defaults）：config-br-defaultsConfigMap 为所有未显式指定spec.config或 Broker 类的 Broker 定义默认值，可设置集群级（clusterDefault）或命名空间级（namespaceDefaults）默认值。管理员如何配置这些默认值的完整说明见 broker-configuration.md。默认的config-br-defaults内容如下：

apiVersion: v1 kind: ConfigMap metadata: name: config-br-defaults namespace: knative-eventing data: # Configures the default for any Broker that does not specify a spec.config or Broker class. default-br-config: | clusterDefault: brokerClass: MTChannelBasedBroker apiVersion: v1 kind: ConfigMap name: config-br-default-channel namespace: knative-eventing

从上面的配置可以看出：默认 Broker 类是MTChannelBasedBroker，默认引用knative-eventing命名空间中的config-br-default-channelConfigMap。开发者侧可以在单个 Broker 上覆盖这些默认值，相关选项见 broker-developer-config-options.md。

Knative Broker for Apache Kafka

特性与架构

Knative Broker for Apache Kafka 是 Knative Broker API 的原生实现，直接面向 Apache Kafka，主要特性包括：

控制面（control plane）高可用；
数据面（data plane）水平可扩展；
配置选项极其丰富；
基于 CloudEvents partitioning 扩展提供有序投递；
支持任意 Kafka 版本（遵循 Kafka 官方兼容性矩阵）；
支持两种数据面模式：按命名空间隔离的数据面（data plane isolation）或共享数据面。

架构上，Knative Kafka Broker 分为控制面与数据面两部分：控制面由 controller 组成，负责与 Kubernetes API 通信、监听自定义对象并管理数据面；数据面由kafka-broker-receiver与kafka-broker-dispatcher两个 Deployment 组成，负责监听进入的事件、与 Apache Kafka 交互并把事件投递给 Sink——事件流正是流经这里。

在存储模型上，Knative Kafka Broker 将传入的 CloudEvents 以 Kafka record 形式存储，采用binary content mode：所有 CloudEvent 属性与扩展被映射为 Kafka record 的 header，CloudEvent 的data则对应 record 的 value。相比 structured content mode，binary content mode 在传输与路由上更高效，可避免 JSON 解析，且"侵入性"更小，因此能兼容不理解 CloudEvents 的系统。

前置条件与安装

使用 Kafka Broker 前，集群管理员需先完成 Knative Broker for Apache Kafka 安装：安装 Kafka controller 与数据面后，验证kafka-controller、kafka-broker-receiver、kafka-broker-dispatcher三个 Deployment 处于运行状态（可通过kubectl get deployments.apps -n knative-eventing查看）。

创建 Kafka Broker

一个完整的 Kafka Broker 对象示例如下：

apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: # case-sensitive eventing.knative.dev/broker.class: Kafka # Optional annotation to point to an externally managed kafka topic: # kafka.eventing.knative.dev/external.topic: <topic-name> name: default namespace: default spec: # Configuration specific to this broker. config: apiVersion: v1 kind: ConfigMap name: kafka-broker-config namespace: knative-eventing # Optional dead letter sink, you can specify either: # - deadLetterSink.ref, which is a reference to a Callable # - deadLetterSink.uri, which is an absolute URI to a Callable (It can potentially be out of the Kubernetes cluster) delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: dlq-service

要点：

eventing.knative.dev/broker.class: Kafka注解区分大小写；
spec.config引用一个 ConfigMap，用于定义 Kafka 连接与 topic 参数；
spec.delivery.deadLetterSink可选，支持ref（引用一个 Callable 对象）或uri（绝对 URI，可指向集群外）两种写法。

配置 Kafka Broker

spec.config应引用任意命名空间中的、形如下面的 ConfigMap：

apiVersion: v1 kind: ConfigMap metadata: name: kafka-broker-config namespace: your-namespace data: # Number of topic partitions default.topic.partitions: "10" # Replication factor of topic messages. default.topic.replication.factor: "3" # A comma separated list of bootstrap servers. (It can be in or out the k8s cluster) bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"

参数说明：

配置键	含义	备注
`default.topic.partitions`	topic 分区数	字符串形式的整数
`default.topic.replication.factor`	topic 消息副本因子	必须小于等于集群中 Kafka broker 实例数；例如只有一个 Kafka broker 时该值不应超过`1`
`bootstrap.servers`	bootstrap server 列表，逗号分隔	可位于 Kubernetes 集群内或集群外

该 ConfigMap 默认安装在 Knative Eventing 的SYSTEM_NAMESPACE（即knative-eventing）中，可全局编辑；也可以按 Broker 覆盖——在 Kafka Broker 的spec.config中引用不同命名空间、不同名称的 ConfigMap 即可。

Knative 还支持当前 Kafka 版本所支持的全部 topic 配置项：在 ConfigMap 中添加带default.topic.config.前缀的键即可。例如设置retention.ms：

apiVersion: v1 kind: ConfigMap metadata: name: kafka-broker-config namespace: knative-eventing data: # Number of topic partitions default.topic.partitions: "10" # Replication factor of topic messages. default.topic.replication.factor: "3" # A comma separated list of bootstrap servers. (It can be in or out the k8s cluster) bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092" # Here is our retention.ms config default.topic.config.retention.ms: "3600"

Producer/Consumer 配置：所有 Kafka producer 与 consumer 配置项都可通过修改knative-eventing命名空间中的config-kafka-broker-data-planeConfigMap 来调整（具体参数参考 Apache Kafka 官方 Producer/Consumer 配置文档）。其中值得关注的是auto.commit.interval.ms——Kafka consumer 通过提交 offset 记录最后成功发送的事件，Knative Kafka Broker 每auto.commit.interval.ms毫秒提交一次 offset。官方不推荐每条消息投递成功就提交 offset（会损害性能），而更高的提交间隔意味着更高的重复事件概率（因为 consumer 重启时会从最后提交的 offset 恢复）。Knative Kafka Broker 保证至少一次（at least once）投递，应用可能收到重复事件。

数据面日志：kafka-config-loggingConfigMap 控制数据面组件的日志级别，默认是INFO（JSON 控制台输出）；将<root level="INFO">改为<root level="DEBUG">并重启kafka-broker-receiver与kafka-broker-dispatcher即可开启调试日志：

kubectl rollout restart deployment -n knative-eventing kafka-broker-receiver kubectl rollout restart deployment -n knative-eventing kafka-broker-dispatcher

安全配置

Apache Kafka 支持多种安全特性，Knative Kafka Broker 支持以下组合：

使用SASL认证但不加密；
使用SASL认证 +SSL加密；
使用SSL同时完成认证与加密；
仅使用SSL加密、不做客户端认证。

启用安全特性，只需在broker.spec.config引用的 ConfigMap 中增加一个 Secret 引用：

apiVersion: v1 kind: ConfigMap metadata: name: kafka-broker-config namespace: knative-eventing data: # Other configurations # ... # Reference a Secret called my_secret auth.secret.ref.name: my_secret

Secretmy_secret必须与broker.spec.config引用的 ConfigMap 处于同一命名空间（此处为knative-eventing）。证书与密钥必须为 PEM 格式。

SASL 认证支持的机制：PLAIN、SCRAM-SHA-256、SCRAM-SHA-512，以及用于 AWS MSK IAM 的OAUTHBEARER。以下为四种模式的 Secret 创建命令（将<sasl_mechanism>替换为所选机制，<my_caroot.pem_file_path>等替换为实际文件路径）：

SASL 认证、无加密：

kubectl create secret --namespace <namespace> generic <my_secret> \ --from-literal=protocol=SASL_PLAINTEXT \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-literal=user=<my_user> \ --from-literal=password=<my_password>

SASL 认证 + SSL 加密：

kubectl create secret --namespace <namespace> generic <my_secret> \ --from-literal=protocol=SASL_SSL \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-file=ca.crt=caroot.pem \ --from-literal=user=<my_user> \ --from-literal=password=<my_password>

仅 SSL 加密、无客户端认证：

kubectl create secret --namespace <namespace> generic <my_secret> \ --from-literal=protocol=SSL \ --from-file=ca.crt=<my_caroot.pem_file_path> \ --from-literal=user.skip=true

ca.crt可以省略，此时回退使用系统的根 CA 集合。

SSL 认证 + 加密（双向 TLS）：

kubectl create secret --namespace <namespace> generic <my_secret> \ --from-literal=protocol=SSL \ --from-file=ca.crt=<my_caroot.pem_file_path> \ --from-file=user.crt=<my_cert.pem_file_path> \ --from-file=user.key=<my_key.pem_file_path>

AWS MSK IAM 认证：除创建 Secret 外还需要配置 Java properties。在config-kafka-broker-data-plane的config-kafka-broker-producer.properties与config-kafka-broker-consumer.properties（以及 Kafka Channel 对应的config-kafka-channel-producer.properties/config-kafka-channel-consumer.properties）中追加如下配置：

security.protocol=SASL_SSL sasl.mechanism=OAUTHBEARER sasl.jaas.config=org.apache.kafka.common.security.oauthbearer.OAuthBearerLoginModule required awsStsRegion="<region>"; sasl.login.callback.handler.class=software.amazon.msk.auth.iam.IAMOAuthBearerLoginCallbackHandler sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMOAuthBearerLoginCallbackHandler

若使用 assume IAM role，需在sasl.jaas.config值中追加awsRoleArn="<role_arn>"。随后创建 Secret——使用默认 AWS 凭证：

kubectl create secret --namespace <namespace> generic <my_secret> \ --from-literal=protocol=SASL_SSL \ --from-literal=sasl.mechanism=OAUTHBEARER \ --from-literal=type=OAUTHBEARER \ --from-literal=tokenProvider=MSKAccessTokenProvider

或使用 assume role：

kubectl create secret --namespace <namespace> generic <my_secret> \ --from-literal=protocol=SASL_SSL \ --from-literal=sasl.mechanism=OAUTHBEARER \ --from-literal=type=OAUTHBEARER \ --from-literal=tokenProvider=MSKRoleAccessTokenProvider \ --from-literal=roleARN=<role_arn>

自带 Topic（Bring Your Own Topic）

默认情况下 Knative Kafka Broker 会创建自己的内部 topic，但可以通过kafka.eventing.knative.dev/external.topic注解指向外部托管的 topic：

apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: # case-sensitive eventing.knative.dev/broker.class: Kafka kafka.eventing.knative.dev/external.topic: <my-topic-name> name: default namespace: default spec: # other spec fields ...

注意：使用外部 topic 时，Knative Kafka Broker不拥有也不负责管理该 topic——包括 topic 生命周期及其有效性。此外，对 topic 的一般访问可能还有其他限制，需结合 Kafka 的 ACL（Access Control Lists）机制考虑。

配置事件投递顺序

通过Trigger对象上的kafka.eventing.knative.dev/delivery.order注解可配置投递顺序保证：

apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: my-service-trigger annotations: kafka.eventing.knative.dev/delivery.order: ordered spec: broker: my-kafka-broker subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: my-service

支持的两种消费保证：

unordered（默认）：非阻塞消费者，乱序投递但保留正确的 offset 管理。适合高并发消费且无需显式排序的场景，例如点击数据分析。
ordered：按分区阻塞消费——消费者在收到 CloudEvent 订阅方的成功响应之前，不会投递该分区的下一条消息。适合对排序要求严格、或事件之间存在关联/分组的场景，例如客户订单处理。

数据面隔离 vs 共享数据面

Knative Kafka Broker 的数据面有两种运行模式：

使用KafkaBroker 类时采用共享数据面：集群中所有 Kafka Broker 共用knative-eventing命名空间中的kafka-broker-receiver与kafka-broker-dispatcherDeployment。
使用KafkaNamespacedBroker 类时，Kafka controller 会在每个存在 Broker 的命名空间中创建一套独立数据面，供该命名空间内所有KafkaNamespacedBroker 使用，从而实现数据面隔离。作为隔离的代价，这会创建更多 Deployment、消耗更多资源；除非确有隔离需求，官方推荐使用常规的Kafka类。

创建KafkaNamespacedBroker 的示例：

apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: # case-sensitive eventing.knative.dev/broker.class: KafkaNamespaced name: default namespace: my-namespace spec: config: # the referenced `configmap` must be in the same namespace with the `Broker` object, in this case `my-namespace` apiVersion: v1 kind: ConfigMap name: my-config # namespace: my-namespace # no need to define, defaults to Broker's namespace

spec.config引用的 ConfigMap必须与 Broker 对象在同一命名空间。

生命周期行为：命名空间中创建第一个KafkaNamespacedBroker 时，kafka-broker-receiver与kafka-broker-dispatcherDeployment 被创建到该命名空间；当该命名空间中不再存在任何KafkaNamespacedBroker 时，数据面会被自动删除。

KafkaNamespaced 的配置限制：Kafka类可用的配置机制大多对KafkaNamespaced同样有效，但有如下例外（原因是 Kafka Broker controller 会把相关 ConfigMap/Deployment 从knative-eventing命名空间传播到用户命名空间）：

无法按命名空间配置 producer/consumer 配置（config-kafka-broker-data-plane中的设置会应用到用户命名空间）；
无法按命名空间配置 consumer offset 提交间隔；
无法按命名空间配置 tracing 与 logging（config-tracing、kafka-config-logging会被传播）；
数据面 Deployment 由knative-eventing命名空间传播而来，无法按命名空间定制，与knative-eventing命名空间中的完全一致。

Kafka 功能模板配置：config-kafka-featuresConfigMap（位于knative-eventing命名空间）还提供以下全局模板：

配置键	作用	默认值
`triggers.consumergroup.template`	生成 Trigger 消费组 ID 的 Go text/template 模板	`knative-trigger-{{ .Namespace }}-{{ .Name }}`
`brokers.topic.template`	生成 Broker 内部 topic 名称的模板	`knative-broker-{{ .Namespace }}-{{ .Name }}`
`controller-autoscaler-keda`	是否启用 Kafka dispatcher 的 KEDA 自动扩缩容（Alpha）	`disabled`

KEDA 自动扩缩容

所有负责投递事件的 Knative Kafka 组件（source、channel、broker）都支持用 KEDA 对 dispatcher 数据面做自动扩缩容（Alpha 功能）。启用方式：在config-kafka-featuresConfigMap 中设置controller-autoscaler-keda: enabled，并确保集群中已安装 KEDA。注意该开关会同时作用于所有 KafkaSource、引用 Kafka Broker 的 Trigger 以及引用 KafkaChannel 的 Subscription。每个资源的扩缩容可通过注解定制（autoscaling.eventing.knative.dev/min-scale、max-scale、polling-interval、cooldown-period、lag-threshold），也可通过autoscaling.eventing.knative.dev/class: disabled关闭。完整说明见 keda-configuration.md。

RabbitMQ Broker

特性与前置条件

RabbitMQ Broker 是社区（knative-extensions）提供的 Broker 实现，底层使用 RabbitMQ。创建 RabbitMQ Broker 前，集群管理员需先完成 RabbitMQ Broker 安装：其前置条件包括已安装 Knative Eventing、CertManager（与 RabbitMQ Messaging Topology Operator 集成最方便）、RabbitMQ Messaging Topology Operator，以及可用的 RabbitMQ 实例（可通过 RabbitMQ Cluster Kubernetes Operator 创建）。安装 controller 后验证rabbitmq-broker-controller与rabbitmq-broker-webhook两个 Deployment 正常运行。

创建 RabbitmqBrokerConfig 对象

RabbitMQ Broker 通过自定义资源RabbitmqBrokerConfig（eventing.knative.dev/v1alpha1）描述对 RabbitMQ 集群的连接与队列配置：

apiVersion: eventing.knative.dev/v1alpha1 kind: RabbitmqBrokerConfig metadata: name: <rabbitmq-broker-config-name> spec: rabbitmqClusterReference: # Configure name if a RabbitMQ Cluster Operator is being used. name: <cluster-name> # Configure connectionSecret if an external RabbitMQ cluster is being used. connectionSecret: name: rabbitmq-secret-credentials queueType: quorum

其中：

<rabbitmq-broker-config-name>是你为RabbitmqBrokerConfig对象起的名字；
<cluster-name>是此前创建的 RabbitMQ 集群名称。

name与connectionSecret不能同时设置：name用于与 Broker 同集群运行的 RabbitMQ Cluster Operator 实例，connectionSecret用于外部 RabbitMQ 服务器。

应用该 YAML：

kubectl create -f <filename>

创建 RabbitMQBroker 对象

随后创建 Broker 对象，通过eventing.knative.dev/broker.class: RabbitMQBroker注解指定 Broker 类，并在spec.config中引用上一步创建的RabbitmqBrokerConfig：

apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: RabbitMQBroker name: <broker-name> spec: config: apiVersion: eventing.knative.dev/v1alpha1 kind: RabbitmqBrokerConfig name: <rabbitmq-broker-config-name>

应用：

kubectl apply -f <filename>

配置消息顺序与并行度

默认情况下，RabbitMQ Broker 的 Trigger 会一次消费一条消息以保证顺序。如果事件顺序不重要且希望获得更高吞吐，可通过parallelism注解配置：将parallelism设为n会为该 Trigger 创建n个并发消费的 worker。

apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: high-throughput-trigger annotations: rabbitmq.eventing.knative.dev/parallelism: "10" ...

投递失败处理：delivery 配置

无论哪种 Broker 类，都可借助spec.delivery配置事件投递失败时的处理策略（详见 event-delivery.md）：

参数	作用
`deadLetterSink`	投递失败的事件发送到的 Sink，可为`ref`（引用 Addressable 对象，如 Knative Service）或`uri`
`retry`	投递失败后的重试次数（初始投递不计入，因此总投递次数 = retry + 1），超过后进入死信
`backoffDelay`	重试前的时间延迟，ISO 8601 格式，如`PT1S`表示 1 秒
`backoffPolicy`	重试退避策略，`linear`（固定间隔）或`exponential`（间隔 =`backoffDelay * 2^<重试次数>`）

各 Broker 类对 delivery 参数的支持情况：

Broker 类	支持的投递参数
`Kafka`	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`
`MTChannelBasedBroker`	取决于底层 Channel 实现
`RabbitMQBroker`	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`

此外，Channel 类实现（如 In-Memory、Kafka）在事件最终投递失败并转入 dead letter sink 前，可能会附加knativeerrordest（原始目标 URL）、knativeerrorcode（最终投递尝试的 HTTP 状态码）、knativeerrordata（最终投递尝试的 HTTP 响应体）等扩展属性，可用于错误审计与追踪。

如何选择 Broker 类型

综合以上内容，选型时可以从以下维度权衡：

默认、零依赖：如果集群中尚未部署消息中间件，且主要用于开发验证，可直接使用随 Eventing 发布的MTChannelBasedBroker（配合 InMemoryChannel），但请记住 InMemoryChannel不适合生产；生产环境可搭配 KafkaChannel 等持久化 Channel。
Kafka 生态、强排序与高吞吐：如果已有或计划部署 Apache Kafka，优先选择 Knative Broker for Apache Kafka。它原生集成 Kafka，支持有序/无序投递、丰富的安全特性、BYO topic、控制面 HA 与水平可扩展数据面，是官方推荐的"原生优先"方案。
多租户安全隔离：需要为不同命名空间隔离数据面时，使用KafkaNamespaced类，并接受其更多的资源消耗与配置限制。
RabbitMQ 生态：若团队以 RabbitMQ 为消息基础设施，RabbitMQ Broker 提供了最自然的集成，默认保序，并可通过parallelism注解在吞吐与顺序之间取舍。