Knative Eventing RabbitMQ 正式 GA：Broker 与 Source 的架构、特性与实战配置

文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载Knative 扩展项目 eventing-rabbitmq 已宣布进入 Generally AvailableGA阶段其提供的 API 将在后续迭代中保持稳定。本文以该公告为核心结合本仓库中 RabbitMQ Broker 使用文档、RabbitMQ Source 使用文档 与 安装指南系统讲解其单租户架构、连接任意 RabbitMQ 实例的方式、FIFO 与高吞吐并行模式、Quorum 队列配置、指标观测以及从安装到验证的完整操作步骤帮助你在生产环境中把 RabbitMQ 接入 Knative Eventing 事件链路。一、公告背景从扩展项目到 GA 里程碑Knative 官方博客于 2021 年底发布公告作者 Gab SatchiVMware 高级软件工程师宣布 Eventing RabbitMQ 正式 GA。GA 的意义在于该组件所提供的 API 将在后续迭代中保持稳定用户可以放心地将其用于生产环境不必担心 API 兼容性被频繁破坏。在本仓库的 Knative Eventing 文档体系中RabbitMQ 被列为两种官方支持的替代 Broker 实现之一另一种是 Knative Broker for Apache Kafka参见 Broker 类型总览同时 RabbitMQSource 也是文档中状态标记为Stable稳定的官方 Source其职责是把 RabbitMQ 消息带入 Knative参见 Event sources 总览。二、核心特性总览公告将 GA 版本的核心能力归纳为以下几个维度下文逐一展开可对接任意 RabbitMQ 实例既支持 RabbitMQ Cluster Kubernetes Operator 创建的集群也支持外部实例并行度与事件顺序默认 FIFO 顺序消费可通过parallelism注解切换高吞吐并行模式Quorum 队列默认使用具备容错与复制能力的队列类型且 Trigger 自动继承 Broker 的队列类型指标观测镜像 Knative Eventing 通用指标但因单租户模型不适用Broker - Filter指标单租户架构为每个 Broker / Trigger / Source 创建专属资源持续性能验证每次发布都伴随性能测试套件运行真实落地案例被 VMware Event Broker ApplianceVEBA与 Cloud Native RuntimesCNR等产品采用。三、使用任意 RabbitMQ 实例rabbitmqClusterReference详解公告强调Eventing RabbitMQ 与由 RabbitMQ Cluster Kubernetes Operator 供给的集群配合良好但并非强绑定——它也可以连接通过其他方式供给的 RabbitMQ 实例。这一灵活性的关键在rabbitmqClusterReference字段Broker 与 Source 两个对象都包含该字段。rabbitmqClusterReference支持两种互斥的引用方式引用 Operator 创建的集群通过name字段指定同命名空间内的RabbitmqCluster自定义资源名称引用外部实例的凭据通过connectionSecret.name字段指向一个包含 RabbitMQ 连接凭据的Secret。在 创建 RabbitMQ Broker 文档中明确警告name与connectionSecret不能同时设置。原因在于name指向的是与 Broker 同集群运行的 Operator 实例而connectionSecret指向外部 RabbitMQ 服务器二者语义互斥。3.1 创建 RabbitmqBrokerConfig 对象先在集群中声明 Broker 的底层配置对象RabbitmqBrokerConfigAPI 版本eventing.knative.dev/v1alpha1apiVersion: eventing.knative.dev/v1alpha1 kind: RabbitmqBrokerConfig metadata: name: rabbitmq-broker-config-name spec: rabbitmqClusterReference: # 使用 RabbitMQ Cluster Operator 时配置 name name: cluster-name # 使用外部 RabbitMQ 集群时配置 connectionSecret connectionSecret: name: rabbitmq-secret-credentials queueType: quorum字段说明rabbitmq-broker-config-name你为 RabbitmqBrokerConfig 对象指定的名称cluster-name你此前创建的 RabbitMQ 集群名称queueType: quorum指定底层 RabbitMQ 使用的队列类型详见下文第五节。应用该 YAMLkubectl create -f filename其中filename为上一节创建的文件名。3.2 创建 RabbitMQBroker 对象再通过标注 Broker class 为RabbitMQBroker的 Broker 对象绑定该配置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-config-name即上一步创建的配置对象名。3.3 Source 侧的外部集群引用同理RabbitMQSource 使用文档 中的RabbitmqSource对象也支持完全相同的双模式引用spec: rabbitmqClusterReference: # 使用 RabbitMQ Cluster Operator 时配置 name name: cluster-name # 使用外部 RabbitMQ 集群时配置 connectionSecret connectionSecret: name: rabbitmq-secret-credentials四、并行度与事件顺序FIFO 与高吞吐模式RabbitMQ 默认以先进先出FIFO模式顺序消费事件这在需要严格事件顺序的场景如状态机、账务流水中是正确选择。但公告明确指出存在顺序并非必需、更看重吞吐量的场景。为此Broker 与 Source 均提供parallelism配置允许并行处理多条消息。4.1 Trigger 级别的 parallelismBroker 场景下并行度通过Trigger 注解配置见 RabbitMQ Broker 文档。文档解释默认情况下 Trigger 一次只消费一条消息以保证顺序若事件顺序不重要、需要更高性能可通过parallelism注解配置——将其设为n即为该 Trigger 创建n个 worker 并行消费。以下示例将 Trigger 的并行度设为10apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: high-throughput-trigger annotations: rabbitmq.eventing.knative.dev/parallelism: 10 ...注意注解键为rabbitmq.eventing.knative.dev/parallelism值为字符串形式的数字且位于 Trigger 的metadata.annotations中。4.2 Source 级别的 parallelismSource 侧则是在spec.rabbitmqResourcesConfig.parallelism字段配置见 RabbitMQSource 文档。该字段与exchangeName、queueName一起构成了 Source 在 RabbitMQ 端的资源定义spec: rabbitmqResourcesConfig: parallelism: 10 exchangeName: eventing-rabbitmq-source queueName: eventing-rabbitmq-source其中parallelism: 10Source 消费消息的并行 worker 数量exchangeNameSource 使用的 RabbitMQ exchange 名称queueNameSource 消费消息所用的队列名称。4.3 顺序保证与吞吐的取舍建议从仓库文档的措辞可以看出设计意图FIFO 是默认安全选项parallelism是显式的性能开关。规划生产配置时应依据业务对事件顺序的敏感度做取舍——对顺序敏感的事件流保留默认值对可乱序的海量事件如日志聚合、指标采集通过提高parallelism换取吞吐。原公告中提及的 FIFO 与高吞吐双模式示例trigger-customizations samples正是围绕这一取舍展开的。五、Quorum 队列默认的容错队列类型Quorum 队列是 RabbitMQ 提供的容错、可复制的队列类型适用于多节点集群环境能抵御节点故障导致的数据丢失。公告明确指出RabbitMQ 默认使用 Quorum 队列。队列类型可通过RabbitmqBrokerConfig的spec.queueType字段配置见上文 3.1 节的 YAML。这一设计有一个重要行为任何订阅该 Broker 的 Trigger 都会自动继承 Broker 的队列类型用户无需在每个 Trigger 上重复配置降低了多 Trigger 场景下的配置漂移风险。从仓库文档看queueType的可选值至少包含quorum公告与配置示例均以此为主在多节点生产部署中Quorum 队列凭借复制能力成为默认推荐这也是它被写进官方配置模板的原因。六、单租户架构专属资源带来的收益与开销6.1 架构模型与组件职责Eventing RabbitMQ 采用单租户single tenant模型为每一个 Broker、Trigger 和 Source 对象创建专属的、独立的资源。公告对这种每个对象一套资源的取舍做了明确说明——虽然存在额外开销但带来三方面收益按需自动伸缩Pod 可以针对某个 Broker、Trigger 或 Source 的实际流量进行自动扩缩容autoscale复用既有 RBAC用户的既有策略与角色可直接用于基于角色的访问控制RBAC更高的集群透明度集群上运行了哪些组件一目了然排障与审计更直观。从架构图可见 Broker 侧的完整链路Broker 的创建流程公告原文要点创建 Broker 时系统自动创建一个可接收 CloudEvents 的ingress Pod同时创建路由 CloudEvents 所需的RabbitMQ 资源exchange、队列等Trigger 会创建 dispatcher Pod负责从 RabbitMQ 消费消息并将 CloudEvents 投递到可寻址addressable的目标资源。Source 侧的链路同样清晰RabbitMQSource 的行为公告原文要点RabbitMQSource对象可以从队列中取回消息将其转换为 CloudEvents再发送给可寻址的消费者sink。6.2 与多租户实现的差异单租户模型意味着每个对象拥有独立的 Pod 与独立指标这是它透明度高、可独立伸缩的根源代价则是资源密度相对较低。规划集群容量时需要按 Broker/Trigger/Source 的数量评估 Pod 总数并通过 Knative 的自动伸缩机制缓解静态开销。七、指标与可观测性7.1 指标范围说明公告指出Eventing RabbitMQ镜像了 Knative Eventing 指标 中的一部分。由于单租户架构的特点Broker - Filter指标不适用——因为不存在独立的 filter 组件过滤逻辑由各 Trigger 的 dispatcher 承担因此 Filter 相关的event_count、event_dispatch_latencies、event_processing_latencies等指标不在此列。参照 Knative Eventing 的通用指标定义eventing-metrics.mdBroker Ingress 侧有两类核心指标可被 RabbitMQ Broker 对标| 指标名 | 含义 | 类型 | 典型标签 | | :- | :- | :- | :- | |event_count| Broker 收到的事件总数 | Counter |broker_name、event_type、namespace_name、response_code、response_code_class| |event_dispatch_latencies| 将事件分发到 Channel 所耗时间 | Histogram | 同event_count的标签集合 |Source 侧可对标事件源通用指标| 指标名 | 含义 | 类型 | 典型标签 | | :- | :- | :- | :- | |event_count| Source 发出的事件总数 | Counter |event_source、event_type、name、namespace_name、resource_group、response_code等 | |retry_event_count| Source 重试发出的事件数 | Counter | 同event_count的标签集合 |通过这些指标可以按 HTTP 响应码聚合出两类事件成功2xx与失败5xx从而定位 ingress 与 dispatcher 的健康状况。7.2 投递失败可观测性若事件投递失败还可结合 事件投递失败处理文档 中定义的投递参数与错误属性进行排查。文档中的 Broker 支持表明确列出| Broker Class | 支持的投递参数 | | :- | :- | | googlecloud |deadLetterSink、retry、backoffPolicy、backoffDelay| | Kafka |deadLetterSink、retry、backoffPolicy、backoffDelay| | MTChannelBasedBroker | 取决于底层 Channel | |RabbitMQBroker|deadLetterSink、retry、backoffPolicy、backoffDelay|即 RabbitMQBroker 完整支持死信队列、重试次数、重试退避策略linear或exponential与退避延迟ISO 8601 时长格式如PT1S等标准投递参数。八、性能验证与生产落地8.1 持续性能验证机制公告披露每次发布都会运行一套性能测试套件以确保组件维持足够的吞吐量与可接受的延迟最新一轮的结果会随版本归档。这构成了一种发布即验证的质量门禁吞吐与延迟指标是 GA 承诺的一部分而非事后补救。8.2 已公开的采用方公告列出了两个真实采用方作为生产可用性的佐证VMware Event Broker ApplianceVEBAVMware 的事件代理设备借助 Eventing RabbitMQ 将事件送入 Knative 处理链路Cloud Native RuntimesCNRVMware Tanzu 体系下的云原生运行时同样基于该组件构建事件能力。这两家采用方与公告作者的 VMware 背景一致属于文档明确说明的采用事实可作为评估组件生产成熟度的参考信号。九、从安装到验证的完整实操9.1 前置条件根据 RabbitMQ Broker 安装文档 与 RabbitMQSource 文档需要准备已安装 Knative Eventing已安装CertManager v1.5.4与 RabbitMQ Messaging Topology Operator 集成最顺畅已安装RabbitMQ Messaging Topology Operator推荐搭配 CertManager 使用最新 release一个可用的 RabbitMQ 实例——推荐使用 RabbitMQ Cluster Operator 创建。9.2 安装 RabbitMQ 控制器安装 Broker 控制器kubectl apply -f {{ artifact(orgknative-extensions, repoeventing-rabbitmq, filerabbitmq-broker.yaml) }}安装 Source 控制器kubectl apply -f {{ artifact(orgknative-extensions, repoeventing-rabbitmq, filerabbitmq-source.yaml) }}9.3 验证控制器运行状态Broker 侧验证rabbitmq-broker-controller与rabbitmq-broker-webhook在knative-eventing命名空间运行kubectl get deployments.apps -n knative-eventing示例输出NAME READY UP-TO-DATE AVAILABLE AGE eventing-controller 1/1 1 1 10s eventing-webhook 1/1 1 1 9s rabbitmq-broker-controller 1/1 1 1 3s rabbitmq-broker-webhook 1/1 1 1 4sSource 侧验证rabbitmq-controller-manager与rabbitmq-webhook在knative-sources命名空间运行kubectl get deployments.apps -n knative-sources示例输出NAME READY UP-TO-DATE AVAILABLE AGE rabbitmq-controller-manager 1/1 1 1 3s rabbitmq-webhook 1/1 1 1 4s9.4 创建 RabbitMQSource 并验证事件流转RabbitMQSource 文档 给出了完整可用的 Source 对象模板综合了前文涉及的集群引用、并行度、投递参数与 sink 配置apiVersion: sources.knative.dev/v1alpha1 kind: RabbitmqSource metadata: name: source-name spec: rabbitmqClusterReference: # 使用 RabbitMQ Cluster Operator 时配置 name name: cluster-name # 使用外部 RabbitMQ 集群时配置 connectionSecret connectionSecret: name: rabbitmq-secret-credentials rabbitmqResourcesConfig: parallelism: 10 exchangeName: eventing-rabbitmq-source queueName: eventing-rabbitmq-source delivery: retry: 5 backoffPolicy: linear backoffDelay: PT1S sink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: event-display其中delivery字段的含义与 投递失败处理文档 保持一致retry: 5最多重试 5 次backoffPolicy: linear线性退避也可用exponential此时延迟 backoffDelay × 2^重试次数backoffDelay: PT1SISO 8601 时长即每次重试间隔 1 秒。应用 Sourcekubectl apply -f filename验证事件是否到达 sink示例 sink 为 Knative Serviceevent-display可能需要等待片刻kubectl -lserving.knative.dev/serviceevent-display logs -c user-container示例输出展示了标准的 CloudEvents 结构☁️ cloudevents.Event Context Attributes, specversion: 1.0 type: dev.knative.rabbitmq.event source: /apis/v1/namespaces/default/rabbitmqsources/source-name subject: f147099d-c64d-41f7-b8eb-a2e53b228349 id: f147099d-c64d-41f7-b8eb-a2e53b228349 time: 2021-12-16T20:11:39.052276498Z datacontenttype: application/json Data, { ... Random Data ... }其中type: dev.knative.rabbitmq.event即 RabbitMQSource 产生的 CloudEvent 类型source指向对应的 RabbitmqSource 对象。9.5 清理资源验证完毕后按序删除测试资源# 删除 RabbitMQSource kubectl delete -f source-yaml-filename # 删除 RabbitMQ 凭据 Secret kubectl delete -f secret-yaml-filename # 删除 event-display Service kubectl delete -f service-yaml-filename十、社区反馈与演进预期GA 公告的落点是向社区征集反馈项目团队欢迎用户试用该版本并回报问题与疑问新 issue 可在项目仓库的 issues 页面创建。从仓库文档体系看RabbitMQ Broker 与 RabbitMQSource 均提供了更多 samples 目录与 issue 提交入口供读者继续深入。总结Eventing RabbitMQ 的 GA 公告向用户传递了几个明确信号API 稳定性承诺GA 后保持兼容、灵活的外部集群对接rabbitmqClusterReference双模式、可调的顺序/吞吐权衡parallelism、默认的 Quorum 队列容错、单租户架构下的自动伸缩与 RBAC 友好性以及每次发布伴随的性能门禁。结合本仓库的 Broker、Source 与安装文档你可以在自己的集群上快速复现从安装控制器、创建RabbitmqBrokerConfig/RabbitmqSource、配置投递参数到观测 CloudEvents 落地的完整流程为生产级事件驱动架构选型提供直接依据。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐Knative Eventing 事件驱动架构实战指南Source、Broker、Trigger 与事件流Knative Eventing 事件驱动架构实战指南Source、Broker、Trigger 与事件流 Knative Eventing 是 Knativ文档教程云原生Knative Eventing GitLab Source 实战把 GitLab 项目事件接入 Knative ServiceKnative Eventing GitLab Source 实战把 GitLab 项目事件接入 Knative Service 导读 GitLab Sour文档教程云原生Knative Eventing 中 Apache Kafka Channel 的安装、配置与实战指南Knative Eventing 中 Apache Kafka Channel 的安装、配置与实战指南 本篇技术指南以 code samples/eventin文档教程云原生创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考