简述

本文用来记录 Kubernetes 上部署的 RabbitMQ 集群遇到的一个问题。基础信息如下：

  • 宿主机系统：Centos 7.8
  • Docker Server版本：18.09.6
  • Kubernetes版本：v1.19.0
  • RabbitMQ部署方式：stx-openstack 3.0
  • RabbitMQ镜像版本：3.7.13

问题描述

3节点集群，由于非同时节点关机（如机房掉电），概率导致集群仲裁失败。故障现象是pod 为Running 状态，但是几分钟以后依然不能readay 1/1。pod日志显示” Waiting for Mnesia tables”

问题原因

rabbitmq集群pod分0、1、2，共3节点。服务器掉电，最后退出的pod认为自己具有最新的数据，所以启动时应从最后退出的pod启动。但Kubernetes Statefulset维护的pod，启动方式为0 - 1 - 2顺序启动，只有0运行起来后才会运行后面的pod。如果0不是最后退出，则会启动卡住，等待最后退出的节点运行，形成死循环

解决办法

pod 0 启动方式调整为强制启动，删除pod后自动重建，会强制拉起。命令如下：

1
2
3
4
# Ensures that the node will start next time, even if it was not the last to shut down.
# Force boot cluster shut down unexpectedly in an unknown order.
# ref: https://www.rabbitmq.com/rabbitmqctl.8.html#force_boot
rabbitmqctl force_boot

参考文档