【Rook / CSI】排障坐标系：Pending、MountFailed、feature 静默失败与升级卡住
内容提要
本文介绍Rook/CSI在K8s上运行Ceph的故障排查方法，提出六轴归因框架：PVC Pending、MountFailed、RBD特性静默失败、快照未就绪、升级卡住、mon端点/密钥错配。每轴按API、Sidecar、CSI、Rook、Ceph五层顺序排查，强调先选轴再操作，避免盲目重启集群，并给出跨轴并发时的优先级建议。
延伸解读
先选轴再操作，避免盲目重启
文章强调排障第一步是确定症状属于哪个轴，而不是直接重启集群。因为不同轴的根因位于不同层，盲目重启可能冲掉因果链，甚至放大故障。例如，PVC Pending 多与控制面相关，而 MountFailed 多与节点数据面相关。建议先通过 describe、日志等定位轴，再按层排查，避免无谓的集群级操作。
五层排查顺序：从 API 到 Ceph
每个轴都建议按 API、Sidecar、CSI、Rook、Ceph 的顺序排查。API 层看事件和资源状态，Sidecar 看 RPC 返回，CSI 看驱动执行，Rook 看 reconcile 是否创建资源，Ceph 看底层是否接受操作。这种顺序有助于快速定位失败被命名的层，避免直接陷入底层细节。
跨轴并发时的优先级建议
真实事故常同时涉及多轴，文章建议先冻结变更面（如升级未收敛），再保数据面（如 Ceph 健康），然后清控制面（如 Secret、pool），最后处理节点面（如挂载失败）。这样能避免在移动靶上排障，减少噪声，提高效率。
注意静默失败与语义差异
轴三（RBD feature 静默失败）和轴四（快照语义）是容易误判的案例。轴三中，挂载成功但行为异常，且指标双绿，容易让人误判为网络或容量问题。轴四中，CephFS 的目录级快照与卷级快照语义不同，不能简单等同。理解这些差异有助于避免错误排查方向。
Q&A
Rook/CSI 排障时，为什么不能一上来就重启整个 rook-ceph 命名空间？
因为 PVC Pending 和 MountFailed 的根因很少在同一层，前者多在 Controller 路径（provisioner、Secret、pool），后者多在 Node 路径（plugin 注册、map/mount、内核）。重启整个命名空间会冲掉因果链，还可能把可恢复的 mon 抖动放大成双故障。
PVC 一直 Pending，应该按什么顺序排查？
按 API → sidecar → CSI → Rook → Ceph 五层顺序排查。先看 PVC 的 Events 和 StorageClass 的 provisioner 前缀；再看 csi-provisioner 日志中的 gRPC 码；然后看 CSI 驱动容器日志；接着检查 CephBlockPool/CephFilesystem 是否 Ready；最后用 toolbox 确认 pool/fs 是否存在，并测试到 mon 的连通性。
Pod MountFailed 时，如何判断是节点插件问题还是 Ceph 问题？
先看 VolumeAttachment 是否创建，ATTACHED 是否为 true；再检查节点上是否有 csi-rbdplugin/csi-cephfsplugin Pod，driver-registrar 日志中 PluginRegistered 是否为 true；然后看节点插件容器内是否有卡住的 rbd map/mount，dmesg 看内核拒绝原因；最后检查 Ceph 集群是否 HEALTH_ERR 或有大量 slow ops。
RBD feature 静默失败有什么典型症状？
PVC Bound、Pod Running，Events 干净，但应用出现意外只读、依赖某 feature 的路径失败、性能异常或仅在部分节点复现，且 csi_liveness 与 ceph health 都正常。
VolumeSnapshot 一直 readyToUse 为 false，可能是什么原因？
可能原因包括：集群未安装匹配的 snapshot CRD 和 snapshot-controller（Rook 只部署 snapshotter sidecar，不捆绑 controller）；csi-snapshotter 日志报错；RBD 卷级 snap 与 CephFS 目录级 snap 语义不同，CephFS 的 VolumeSnapshot 不代表整卷一致点。
Rook 升级卡住时，应该检查哪些方面？
检查 Rook Operator 日志中的 reconcile 错误，确认是否违反 Ceph 一次一个主版本的闸门；检查 CSI sidecar 镜像 tag 与 CRD 是否匹配；用 ceph versions 确认 Ceph 版本，避免使用 Tentacle v20.2.0 + read affinity 等已知风险组合。
mon endpoint 或 Secret 错配时，如何验证？
在 provisioner 驱动容器内用同一 key 和 -m 手工运行 rbd ls，如果能复现错误，则问题锁定在凭据或端点；同时检查 StorageClass 注解的 secret-name 是否指向存在的 Secret，CSI 配置中的 mon endpoint 是否与当前 mon Service/IP 一致。
当多个轴的症状同时出现时，排障优先级是什么？
先停变更面：若升级未收敛，冻结继续升版本或改 CR；再保数据面：若 Ceph 已 HEALTH_ERR 或大量 inactive PG，先接 ceph/16；再清控制面：处理轴一/六（Secret、pool、endpoint）；最后清节点面：按节点处理轴二/三，避免全集群重启 plugin。
