rook-ceph故障排查记录 目录一、前言二、故障现象三、初步调试四、故障排查操作五、降级MON副本操作一、前言记一次测试环境rook-ceph故障排查始末故障原因为使用nerdctl创建测试容器后多个节点创建了nerdctl0网桥导致calico组件故障记录本文为排查故障和rook-ceph特殊操作参考。基础环境kubernetes v1.30.1rook-ceph release-1.19.0nerdctl v2.1.1containerd v2.1.0二、故障现象登录rook-ceph-dashboard页面可查询到日志如下MON_DOWN: 1/3 mons down, quorum b,c mon.a (rank 0) addr [v2:10.97.242.52:3300/0,v1:10.97.242.52:6789/0] is down (out of quorum) PG_AVAILABILITY: Reduced data availability: 1 pg inactive pg 1.0 is stuck inactive for 6d, current state undersizedpeered, last acting [1] PG_DEGRADED: Degraded data redundancy: 1 pg undersized pg 1.0 is stuck undersized for 6d, current state undersizedpeered, last acting [1] POOL_NO_REDUNDANCY: 3 pool(s) have no replicas configured pool replicapool has no replicas configured pool sata-myfs-metadata has no replicas configured pool sata-myfs-replicated has no replicas configured本次环境为单主机三硬盘测试搭建搭最小副本可行性故告警内的PG异常和存储池高危配置忽略不计由日志可看出问题在于MON集群故障节点a离线导致仲裁票数不足集群只读 / 阻塞、无法正常数据调度此时测试业务还在正常运行但是新建PVC失败会一直pending。三、初步调试查询故障mon-a的日志可查询到关键信息mon.a0(probing) e3 handle_auth_request failed to assign global_id1mon-a本地 RocksDB 元数据正常加载完成MON 进程正常启动、绑定端口成功2但 mon.a 始终处于 probing 探测状态无法加入仲裁集群认证阶段无法从当前 quorummon.b、mon.c申请分配全局 ID3表现为MON 进程活着但一直探测、无法加入集群长时间重试认证失败最终被判定 down。常见诱因如下1集群时间不同步最常见三个 MON 节点宿主机时间偏差过大Ceph 认证基于时间戳校验直接拒绝分配 global_id2集群密钥损坏ceph.client.admin.keyring、mon.keyring 多节点不一致3原有 MON 残留集群信息异常Paxos 仲裁同步卡住4网络问题mon.a Pod 可以通集群内网但安全策略 / 防火墙 / NetworkPolicy 拦截了 MON 之间 6789、3300 端口互访。#由于所有pod均running未注意部分calico未ready初期未排查网络个人失误登录tool容器执行命令查询mon仲裁状况rootrook-node1:~# kubectl exec -it deploy/rook-ceph-tools -n rook-ceph -- bash bash-5.1$ ceph mon stat查询命令卡死初步判断为Ceph MON 集群仲裁不满足导致无法查询。四、故障排查操作执行下列命令试图绕过仲裁阻塞删除mon-arootrook-node1:~# kubectl exec -it deploy/rook-ceph-tools -n rook-ceph -- bash -c ceph --mon-hostmon.b,mon.c mon remove a server name not found: mon.b (Name or service not known) unable to parse addrs in mon.b,mon.c 2026-06-18T11:07:12.5530000 7f96e3b17640 -1 monclient: get_monmap_and_config cannot identify monitors to contact [errno 22] RADOS invalid argument (error connecting to the cluster) command terminated with exit code 1此时怀疑为tools 容器内无法解析该短域名必须使用MON 实际集群 IP而非服务名故使用命令查询对应IP使用IP重试删除命令rootrook-node1:~# kubectl -n rook-ceph get svc | grep mon rook-ceph-mon-a ClusterIP 10.99.156.163 none 6789/TCP,3300/TCP 3d19h rook-ceph-mon-b ClusterIP 10.99.235.118 none 6789/TCP,3300/TCP 3d19h rook-ceph-mon-c ClusterIP 10.99.12.177 none 6789/TCP,3300/TCP 3d19h rootrook-node1:~# kubectl -n rook-ceph get pods | grep mon rook-ceph-mon-a-5dd9cc8c77-h2dqd 2/2 Running 0 3d19h rook-ceph-mon-b-5fd88bd66c-bcv6v 2/2 Running 0 3d19h rook-ceph-mon-c-dbffdd9b5-pf7nk 2/2 Running 0 3d19h rootrook-node1:~# kubectl exec -it deploy/rook-ceph-tools -n rook-ceph -- bash -c ceph --mon-host10.99.235.118,10.99.12.177 mon remove a使用IP操作也会卡死尝试进入容器b内部进行执行rootrook-node1:~# kubectl -n rook-ceph exec -it rook-ceph-mon-b-5fd88bd66c-bcv6v -- bash Defaulted container mon out of: mon, log-collector, chown-container-data-dir (init), init-mon-fs (init)此时判断mon-a一直处于探测认证失败状态整个 MON 集群 Paxos 仲裁锁卡死现在不论进 tools 还是 mon 容器都会阻塞等待集群仲裁响应常规 ceph 管理命令全部无法执行尝试走强制降级 MON 副本的兜底方案来解锁集群。五、降级MON副本操作由于ceph-mon 进程是pod的形式存在RocksDB 文件锁无法释放故直接在本地安装ceph工具停止服务等操作无法执行最终方案为启动特权测试容器挂载主机节点的 /var/lib/rook/mon-c/data 目录#缩容operator避免mon容器启动RocksDB 文件锁无法释放 rootrook-node1:~# kubectl scale deploy rook-ceph-operator --replicas0 -n rook-ceph rootrook-node1:~# kubectl delete deploy rook-ceph-mon-b rook-ceph-mon-c -n rook-ceph #修改mon的data删除故障节点a的IP只使用bc的IP rootrook-node1:~# kubectl edit configmap rook-ceph-mon-endpoints -n rook-ceph data: b10.99.235.118:6789,c10.99.12.177:6789 rootrook-node2:~# nerdctl run -it --rm --privileged -v /var/lib/rook/mon-b/data:/var/lib/ceph/mon/ceph-b -v /var/lib/rook:/var/lib/rook mon镜像名称 bash-5.1$ ceph-mon --id b --mon-data /var/lib/ceph/mon/ceph-b --conf /dev/null --extract-monmap /tmp/monmap bash-5.1$ monmaptool --rm a /tmp/monmap bash-5.1$ ceph-mon --id b --mon-data /var/lib/ceph/mon/ceph-b --conf /dev/null --inject-monmap /tmp/monmap bash-5.1$ exit #在c节点执行相同的操作即可完成a节点的删除如上完成mon配置文件的修改后还是无法完成选举。重新排查集群状态时发现calico-node仅running长时间没有ready查询日志后发现是故障发生前使用nerdctl创建容器默认创建了nerdctl0网桥使用了10.4.0.1IP全节点冲突导致删除该网桥重启calico组件通信问题消失手动恢复rook-ceph的三节点仲裁一切正常。六、总结kubernetes内服务故障时优先查询kube-system等组件的状态先确认所组件ready再排查具体业务pod的问题。后续使用nerdctl工具时需注意nerdctl命令仅用于管理镜像在kubernetes内创建容器只使用kubectl避免nerdctl0网桥的影响。