Rook-Ceph v1.13部署Ceph v18.2.2时Monitor Pod循环崩溃故障排查

嘿，我最近刚好处理过同款问题——在部署Rook-Ceph v1.13搭配Ceph v18.2.2时，Monitor Pod反复崩溃重启，从你提供的debug日志里，咱们能揪出关键问题：

先看看这份核心日志内容：

debug 2024-07-01T15:25:42.499+0000 7f43a7779700  1 mon.d@1(peon).paxos(paxos active c 2794..3317) lease_timeout -- calling new election
debug 2024-07-01T15:25:42.500+0000 7f43a4f74700  0 log_channel(cluster) log [INF] : mon.d calling monitor election
2024-07-01T19:25:42.503030854+04:00 debug 2024-07-01T15:25:42.501+0000 7f43a4f74700  1 paxos.1).electionLogic(2904) init, last seen epoch 2904
debug 2024-07-01T15:25:42.549+0000 7f43a4f74700  1 mon.d@1(electing) e7 collect_metadata :  no unique device id for : fallback method has no model nor serial
debug 2024-07-01T15:25:43.777+0000 7f43ab183700  0 log_channel(audit) log [DBG] : from='admin socket' entity='admin socket' cmd='mon_status' args=[]: dispatch
2024-07-01T19:25:43.780274539+04:00 debug 2024-07-01T15:25:43.777+0000 7f43ab183700  0 log_channel(audit) log [DBG] : from='admin socket' entity='admin socket' cmd=mon_status args=[]: finished

关键问题定位 #

日志里最显眼的就是这句：no unique device id for : fallback method has no model nor serial——Ceph Monitor默认要求每个节点的存储设备有唯一ID（通过model和serial号生成），如果你的节点用的是虚拟磁盘、云盘或者特殊存储设备，系统读不到这些信息，就会导致Monitor无法完成身份校验，进而触发租约超时、选举失败，最终Pod崩溃重启。

解决方案步骤 #

• 先确认节点磁盘信息
  登录到运行mon.d的节点，执行以下命令检查磁盘的model和serial字段：

lsblk -o NAME,MODEL,SERIAL

如果输出里这些字段是空的，那就坐实了咱们的判断。

• 修改Rook配置跳过设备ID校验
  在你的CephCluster CR配置中，给Monitor添加额外配置，关闭强制要求唯一设备ID的检查：

spec:
  monitors:
    count: 3  # 这里改成你实际的mon数量
    config:
      mon require unique device id: "false"

• 应用配置并验证
  执行kubectl apply -f your-ceph-cluster.yaml更新配置，然后重启Monitor Pod：

kubectl delete pod -n rook-ceph -l app=rook-ceph-mon

之后观察Pod状态，如果不再崩溃，并且执行ceph mon stat能看到正常的quorum状态，就说明问题解决了。

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