Rook-Ceph部署常见故障包括：Operator权限不足需同步ClusterRoleBinding命名空间；CephBlockPool因crush rule或pg_num不匹配导致rbd map失败；CephFileSystem因MDS未就绪或fscache不支持致mount失败；RGW因Ingress TLS证书链错位或backend-protocol配置错误致endpoint不可达。
rook-ceph operator 部署失败：ClusterRoleBinding 权限不生效
Operator 启动后 rook-ceph-operator Pod 一直 CrashLoopBackOff，日志里反复出现 error getting ceph version: failed to run stdcmd 或 no RBAC policy matched —— 这大概率不是 Ceph 自身问题，而是 Operator 没拿到足够权限去操作 CRD 和节点资源。
关键点在于 Rook 的 clusterrolebinding 默认绑定的是 system:serviceaccounts:rook-ceph 这个 ServiceAccount，但如果你手动改过命名空间、或用 Helm 覆盖了 namespace 参数，而没同步更新 ClusterRoleBinding.subjects[0].namespace，权限就断了。
- 检查
kubectl get clusterrolebinding rook-ceph-operator -o yaml，确认subjects[0].namespace和你实际部署 operator 的 namespace 一致 - 如果用了自定义 namespace（比如
storage-ceph），必须同步 patchClusterRoleBinding和所有ServiceAccount、RoleBinding的 namespace 字段 - Helm 部署时别只改
namespace，还要显式设operator.namespace=storage-ceph，否则 Chart 内部模板仍会生成默认值
cephblockpool 创建后 rbd map 失败：底层 crush rule 或 pg_num 不匹配
Pool 创建成功，Ceph 状态也显示 HEALTH_OK，但应用 Pod 挂载 PVC 时卡在 Waiting for a volume to be created，或者直接报 rbd: sysfs write failed。这时候不是网络或密钥问题，而是 pool 的底层配置和集群当前 crush topology 或 PG 数量不兼容。
Rook 默认创建的 CephBlockPool 使用 replicated_rule，但如果集群只有 3 个 OSD 且都落在同一 host 或 rack，而 rule 却要求跨 failure domain（比如 rack），就会无法选到满足条件的 OSD 组合，导致写入失败。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
ceph osd crush rule dump看 rule 定义，再用ceph osd crush rule ls确认 pool 实际绑定的 rule 名 - 检查
CephBlockPool.spec.failureDomain是否和你的物理拓扑一致；若只有单机测试环境，应设为host，并确保对应 rule 的steps中包含take default→chooseleaf firstn 0 type host -
pgNum必须是 2 的幂，且不能超过osd_pool_default_pg_num（通常为 128）；生产环境建议按 OSD 数 × 100 计算，但首次部署别超过 512，否则 PG 创建慢、OSD 同步压力大
CephFileSystem mount 失败：MDS 未就绪或 kernel client 不支持 fscache
PVC 绑定成功，但 Pod 里 mount -t ceph 报 Connection refused 或卡住几秒后超时 —— 先看 ceph status 里有没有 mds 进程，再查 kubectl -n rook-ceph get pod -l app=rook-ceph-mds 是否 Running。即使 MDS Pod 是 Running，也可能因配置错误没真正提供服务。
Rook 的 CephFilesystem CR 默认启用 dashboard 和 fscache，但多数内核版（尤其 CentOS 7.9 / Ubuntu 20.04 默认 kernel）不支持 fscache，会导致 mount 尝试 fallback 失败。
- 确认 MDS Pod 日志有
mds.<fsname>: all is fine</fsname>，而非standby-replay或failed to start - 在客户端节点执行
modprobe ceph; echo $?验证内核模块加载；若失败，检查是否启用了ceph-fuse替代方案（需在 StorageClass 中设mountOptions: ["fuse"]） - 禁用 fscache：编辑
CephFilesystem，把spec.metadataServer.activeCount设为 1，并在spec.metadataServer.parameters加fscache: "false"
对象存储 RGW endpoint 不可达：Ingress 路由与 TLS 证书链错位
RGW Pod Running，ceph orch ps | grep rgw 显示 running，但 curl -v http://rgw.example.com 返回 502 或连接拒绝。Rook 默认用 NodePort 暴露 RGW，但生产环境一般走 Ingress —— 这里最容易被忽略的是证书链顺序和 Ingress controller 对 backend-protocol: HTTPS 的支持差异。
Nginx Ingress 默认不校验 backend TLS 证书，但如果你用了 cert-manager + Let's Encrypt，它签发的证书不含中间 CA，而某些 RGW 镜像（如 v18.2.0+）启用 ssl_verify_peer 后会拒接不完整链的请求。
- RGW Service 类型必须是
ClusterIP，Ingress 的backend.service.port.number应指向 RGW 的https端口（通常是 443），不是 80 - cert-manager Issuer 必须设
preferredChain: "ISRG Root X1"，避免使用已弃用的 DST Root CA X3 - 确认 Ingress annotation 包含
kubernetes.io/ingress.class: nginx和nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"，否则流量以 HTTP 发给 RGW 的 HTTPS 端口
ceph -s 输出里的 pgs 状态、mds rank 和 rgw service endpoint 的真实响应码，比反复重装 operator 有用得多。 
