OpenStack 控制节点故障时，API 服务为何长时间不可用（RabbitMQ 问题）？

这是一个来自 Ubuntu 社区的真实 Bug 报告：OpenStack HA 集群中一个控制节点宕机（或 K8s 节点下线）后，API 服务出现长达 10 分钟甚至更久的不稳定或完全无响应。

现象

• 单控制节点宕机 → API 整体不稳定；
• rabbitmqctl 命令本身都无法响应，说明消息队列已陷入异常；
• 节点宕机约 4 分钟恢复 SSH 可达，但服务完全稳定耗费约 15 分钟，总恢复时间长达 30 分钟。

根因

核心在 RabbitMQ 集群：节点意外退出后，RabbitMQ 的恢复机制与 K8s 环境下 traefik 等负载均衡器的健康检查 / Endpoint 更新延迟叠加，导致：

1. RabbitMQ 集群进入不稳定状态，所有依赖消息队列的 API 服务被拖垮；
2. 负载均衡器未及时摘除死亡端点，流量仍被转发到已不可用的 Pod/节点。

启示

HA 不只是”组件多活”，更要关注故障恢复时的复杂联动效应：

• 消息队列（RabbitMQ）的脑裂/恢复策略要提前演练；
• LB 的健康检查阈值与 Endpoint 收敛速度要匹配故障切换时间；
• 恢复时长 = 网络可达 + 组件自愈 + 流量收敛，三项串行叠加，往往远超直觉。

小结

控制节点故障的杀伤力常被低估。RabbitMQ 与 LB 的联动恢复是关键薄弱点，生产环境务必做故障注入演练，测出真实 RTO。