RabbitMQ pub/sub触发Kubeflow流水线如何规避常驻订阅应用？

核心结论 #

原生Kubeflow没有内置直接从RabbitMQ拉取消息触发流水线的能力，但可以通过Kubeflow生态适配的Serverless组件实现你的需求，完全无需自行维护业务侧常驻订阅应用。

具体实现方案 #

使用Kubeflow生态默认兼容的Knative Eventing RabbitMQ源组件即可，操作步骤如下：

• 部署Knative Eventing及RabbitMQ Source控制器到Kubeflow所在的K8s集群，该控制器属于集群级通用组件，不属于业务侧需要维护的应用范畴
• 创建fanout类型的RabbitMQ exchange，为每个需要触发流水线的订阅方创建专属持久化队列并绑定到该exchange，持久化队列可以解决无订阅者时消息丢失的问题，新订阅方上线后可消费历史未处理消息
• 配置RabbitMQ Source对接对应队列，指定触发动作为调用Kubeflow Pipelines的REST API
• 消息发布到exchange后，Knative会自动拉起临时Pod消费消息、触发流水线，消息处理完成后Pod自动销毁，全程无需要你维护的业务侧常驻服务

场景适配说明 #

• 如需实现pub/sub多消费者能力，仅需要为每个消费者创建独立的RabbitMQ Source以及绑定到同一个fanout exchange的专属队列即可，每条消息会广播到所有绑定队列，触发不同的流水线逻辑
• 你当前使用的AmazonMQ（RabbitMQ兼容版）可以直接复用现有实例配置，无需修改原有消息发布逻辑，仅需要为Knative RabbitMQ Source配置对应访问凭证即可
• 如果你不需要保留历史消息，可以将队列设置为临时队列，消费者下线后队列自动删除，节省存储资源

该方案完全规避了你提到的需要自行开发部署常驻订阅应用、SAM轮询的问题，同时满足fanout模式的pub/sub需求和消息持久化需求。

内容的提问来源于stack exchange，提问作者Shiplu Mokaddim