【Rook / CSI】Rook Operator 与 CRD：CephCluster 所有权边界
内容提要
Rook是Ceph的Kubernetes Operator，通过CRD声明期望状态并调和出守护进程。核心CRD包括CephCluster、CephBlockPool等，v1.20起CSI调谐由Ceph-CSI Operator负责。Rook不管理RADOS内核语义，数据面问题需转向Ceph自身。排障时需明确对象归属、权威控制器及变更来源，避免误判。
延伸解读
所有权边界：排障时先问“谁负责”
文章强调，Rook 与 CSI 是两条独立控制面，混为一谈会导致排障时找不到负责人。例如，PVC 卡在 Pending，可能是 Rook Operator 未调和出 OSD，也可能是 CSI CreateVolume 失败。因此，排障时应先判断现象属于哪类对象（CR、Pod、PVC 还是 Ceph 状态），再确定权威控制器（Rook Operator、Ceph-CSI Operator 或 Ceph 本身），避免误操作。
reconcile 的“拉回”效应：手工修改可能被覆盖
Rook Operator 会持续调和状态至期望值，因此临时手工修改 Deployment 环境变量等操作，通常会被下一轮 reconcile 覆盖。反之，若 CR 中设备过滤器写错，会表现为 prepare Job 反复失败。GitOps 与手工 hotfix 混用时，应以 CR 为权威，将热修写回仓库，否则可能出现“昨晚修好、今早又坏”的假故障。
v1.20 起 CSI 配置权威转移
自 Rook v1.20 起，CSI 驱动的调谐由 Ceph-CSI Operator 负责，不再通过 Rook 的旧 ConfigMap 键值管理。这意味着，修改 CSI 设置应通过 csi.ceph.io 的 OperatorConfig 或 Driver 资源，而非 rook-ceph-operator-config。安装时需确认 csi-operator.yaml 及 RBAC 已就位，再配置 StorageClass。
Rook 不管理 RADOS 内核语义
Rook 负责编排 Ceph 守护进程的生命周期与接线，但 RADOS 内核语义（如 PG peering、BlueStore 延迟）仍由 Ceph 自身管理。排障到数据面问题时，必须使用 ceph/ 坐标系（如 toolbox 中的 ceph status），而非仅看 Kubernetes 对象。文章强调，只有控制面与数据面同时健康，系统才既“存得对”又“坏得可查”。
Q&A
Rook 是什么？它和 Ceph 的 CSI 有什么区别？
Rook 是 Ceph 的 Kubernetes Operator，它通过自定义资源（CRD）声明期望状态，并调和出 Ceph 守护进程（如 mon、mgr、osd）。CSI 解决的是 PVC 如何变成后端卷的问题，而 Rook 解决的是 Ceph 守护进程如何在 Kubernetes 里被声明式地养活。两者是不同层面的东西，不能混为一谈。
Rook 的核心 CRD 有哪些？它们各自的作用是什么？
Rook 的核心 CRD 包括：CephCluster（声明一个 Ceph 集群，管理 mon/mgr/osd 生命周期）、CephBlockPool（创建/更新块池，供 RBD StorageClass 引用）、CephFilesystem（管理 CephFS 和 MDS）、CephObjectStore（部署 RGW 对象网关）、CephObjectStoreUser（管理对象存储用户）等。
在 Rook v1.20 中，CSI 调谐的权威控制器是谁？
在 Rook v1.20 中，CSI 调谐的权威控制器是 Ceph-CSI Operator，而不是 Rook Operator。Rook 不再通过旧 ConfigMap 键值拥有 CSI 设置。
Rook Operator 拥有哪些资源的所有权？
Rook Operator 拥有守护进程编排（如 mon、mgr、osd 的创建和滚动）、设备与存储选择（如 useAllDevices、deviceFilter、storageClassDeviceSets）、集群级生命周期钩子（如健康检查、升级编排、PDB/disruption），以及将 Ceph 连接信息提供给消费方（如 mon endpoints、密钥 Secret）。
Rook 明确不做什么？数据面问题应该去哪里解决？
Rook 不解释 RADOS 内核语义，例如 PG peering、BlueStore 延迟、RBD 对象命名等。数据面问题应转向 Ceph 自身（ceph/ 系列文档）和 Ceph 工具。Rook 只负责编排 Ceph 在 Kubernetes 上的生命周期与接线。
在 Rook 中，如果临时手工修改了 Deployment 的环境变量，会发生什么？
临时手工修改 Deployment 环境变量通常会被下一轮 reconcile 覆盖，因为 Rook Operator 会持续重试将状态拉向期望状态。因此，应该以 CR 为权威，将热修回写进仓库，否则会出现“昨晚修好、今早又坏”的假故障。
Rook 中多集群部署时有哪些约束？
同一命名空间内通常不支持多个集群；多集群时必须避免设备与 hostPath 冲突。dataDirHostPath 必须每集群唯一，且不要使用 /etc/ceph、/rook、/var/log/ceph 及其子路径。另外，CSI 驱动名前缀和命名空间引用也需要相应调整。
Rook 的 Day-2 操作重点是什么？
Rook 的 Day-2 操作重点是声明式升级、PDB/disruption 管理、与 Kubernetes 节点生命周期对齐。磁盘更换、CRUSH 细则、深度 scrub 策略等仍需回到 Ceph 自身工具和文档。
