哥们，太懂你这种老前端动不了，只能在后端和K8s层面死磕的处境了！你的问题核心其实不是K8s本身的配置，而是消息中间件的使用模式没选对，先给你理清楚问题根源，再给你具体的解决办法：

问题根源：你用了「队列独占消费」模式，而非「发布订阅广播」模式 #

你之前试的Google Cloud Pub/Sub、RabbitMQ，默认如果用普通队列的话，消息是轮询分发给消费者的——也就是一条消息只会被一个Pod拿到，这就是为啥只有一个Pod能触发通知。而你需要的是「一条消息发出去，所有Pod都能收到」的广播效果，这就得用消息中间件的发布/订阅（Pub/Sub）模式。

具体解决方案 #

方案1：调整消息中间件的使用方式（最靠谱）

针对Google Cloud Pub/Sub

• 不要用队列拉取的方式，而是让每个Pod都作为独立订阅者，订阅同一个主题。
• 每个Pod启动时，就创建（或复用）一个订阅实例绑定到目标主题上，这样主题里的每一条消息都会推送给所有订阅的Pod。
• 每个Pod收到消息后，直接遍历自己维护的SSE连接列表，给所有连在这个Pod上的客户端发送事件通知。

针对RabbitMQ

• 放弃普通队列，改用Fanout（扇出）交换机：
  • 先创建一个Fanout类型的交换机；
  • 每个Pod启动时，自动创建一个属于自己的临时队列，并把这个队列绑定到Fanout交换机上；
  • 当触发请求的Pod向交换机发送消息时，交换机就会把消息广播到所有绑定的队列，每个Pod都能拿到消息，再推给自己的客户端。

方案2：后端层面的补充优化

不管用哪种消息中间件，每个Pod都要做好两件事：

• 维护自己的SSE连接池：把每个客户端的EventSource连接对象存在内存里（或者用轻量的内存数据库）；
• 定期清理无效连接：比如检测连接是否断开，及时从池子里移除，避免内存泄漏。

额外提醒 #

你用的是ClusterIP Service，这个配置没问题——客户端请求会被K8s的Service负载均衡到任意Pod，但只要消息中间件的广播模式搞定，不管触发请求到哪个Pod，都能把通知同步给所有Pod的客户端。而且老前端的EventSource完全不用改，只要后端的SSE接口正常返回text/event-stream格式的事件就行。

备注：内容来源于stack exchange，提问作者Vlad Tanase