3. Rook Operator 架构：工作原理、CRD 资源定义与部署模式
Rook Operator 是 Rook 控制面的核心组件，它通过 Kubernetes 原生的 Operator 模式，将 Ceph 存储集群的部署、配置、扩缩容、升级和故障恢复等运维操作自动化。理解 Rook Operator 的架构是掌握 Rook Ceph 存储平台的基础。
3.1 Rook Operator 工作原理
Rook Operator 本质上是一个运行在 Kubernetes 集群中的自定义控制器。它遵循 Kubernetes 的“声明式”管理哲学，通过持续监听集群状态，确保实际状态与用户定义的期望状态一致。
kubectl 或 API 创建/修改 Rook 自定义资源（CR） → Rook Operator 通过 Informer/Watch 机制感知资源变化 → Operator 内部的 Reconciler 循环执行调谐逻辑 → 调用 Ceph 管理工具（如 ceph、rados）或 Kubernetes API 创建/更新/删除对应的 Pod、Service、ConfigMap 等资源 → 最终使 Ceph 集群达到期望状态。
下图展示了 Rook Operator 的核心工作流程与组件交互关系：
3.2 CRD 资源定义
Rook 通过自定义资源定义（CRD）扩展 Kubernetes API，将 Ceph 存储组件抽象为 Kubernetes 原生资源。以下是 Rook Ceph 中最核心的 CRD 资源及其用途：
| CRD 名称 | API 版本 (示例) | 用途描述 | 关键字段 |
|---|---|---|---|
| CephCluster | ceph.rook.io/v1 |
定义整个 Ceph 存储集群的配置，包括 MON、MGR、OSD、MDS 等守护进程的规格、存储配置、网络设置等。 | spec.mon, spec.storage, spec.network |
| CephBlockPool | ceph.rook.io/v1 |
定义 RADOS 块设备（RBD）存储池，用于提供持久化块存储（如 PVC 使用 rook-ceph-block StorageClass）。 |
spec.replicated.size, spec.erasureCoded |
| CephFilesystem | ceph.rook.io/v1 |
定义 CephFS 文件系统，包含多个数据池和元数据池，用于提供共享文件存储（如 PVC 使用 rook-cephfs StorageClass）。 |
spec.metadataPool, spec.dataPools, spec.metadataServer |
| CephObjectStore | ceph.rook.io/v1 |
定义 RADOS 网关（RGW）对象存储，提供兼容 S3 的对象存储服务。 | spec.gateway, spec.dataPool, spec.metadataPool |
| CephNFS | ceph.rook.io/v1 |
定义 NFS-Ganesha 导出，允许通过 NFS 协议访问 CephFS 或 RGW 中的数据。 | spec.rados, spec.server |
| CephClient | ceph.rook.io/v1 |
管理 Ceph 认证用户和密钥，用于外部应用或 Kubernetes 组件访问 Ceph 集群。 | spec.caps |
CephCluster 时，务必根据节点硬件配置（如磁盘类型、网络带宽）合理设置 spec.storage.nodes 和 spec.resources，避免资源争抢。对于生产环境，建议使用 storageClassDeviceSets 管理 OSD，以获得更好的设备生命周期管理。
3.3 部署模式
Rook Operator 支持多种部署模式，以适应不同的集群环境和运维需求。主要分为以下三种：
3.3.1 标准 Kubernetes 部署模式
这是最常用的模式，Operator 作为 Deployment 运行在 Kubernetes 集群中，管理同一集群内的 Ceph 守护进程。所有组件（MON、OSD、MGR、MDS、RGW）都以 Pod 形式运行。
- 适用场景： 大多数生产环境，Operator 与 Ceph 集群共存于同一个 K8s 集群。
- 部署方式： 使用
kubectl apply -f deploy/examples/operator.yaml和cluster.yaml。 - 优势： 部署简单，Operator 可直接管理 Pod 生命周期，故障恢复快。
3.3.2 外部集群模式
Rook Operator 管理一个运行在 Kubernetes 集群外部的 Ceph 集群。Operator 仅负责创建访问外部集群所需的 Kubernetes 资源（如 Secret、ConfigMap、StorageClass），而不管理 Ceph 守护进程本身。
- 适用场景： 已有现成 Ceph 集群，希望将其存储能力提供给 K8s 工作负载；或 Ceph 集群由其他工具（如 cephadm）管理。
- 部署方式： 在外部 Ceph 集群上执行
ceph auth get-or-create-key获取密钥，然后在 K8s 中创建CephCluster并设置spec.external.enable: true。 - 优势： 解耦 Ceph 集群与 K8s 集群，运维灵活性高。
3.3.3 多集群管理模式
一个 Rook Operator 实例可以管理多个 CephCluster 资源，这些集群可以位于同一个 K8s 集群的不同命名空间，也可以跨 K8s 集群（需要网络互通）。
- 适用场景： 多租户环境、开发/测试/生产环境隔离、跨地域容灾。
- 部署方式： 部署一个 Operator，然后创建多个
CephCluster资源，每个资源指定不同的namespace和spec。 - 优势： 节省 Operator 资源开销，统一管理面。
spec.dataDirHostPath 和网络端口不冲突。Operator 默认会监听所有命名空间，可以通过 --watch-namespace 参数限制其监听范围，避免权限泄露。
下表总结了三种部署模式的核心差异：
| 特性 | 标准部署模式 | 外部集群模式 | 多集群管理模式 |
|---|---|---|---|
| Ceph 守护进程位置 | K8s Pod 内 | K8s 集群外部 | K8s Pod 内（可跨命名空间） |
| Operator 管理范围 | 完整生命周期 | 仅 K8s 资源 | 多个 CephCluster 实例 |
| 部署复杂度 | 低 | 中（需外部集群准备） | 中（需规划资源隔离） |
| 故障恢复能力 | 自动（Pod 重建） | 依赖外部集群 | 自动（每个集群独立） |
| 典型使用场景 | 新建存储平台 | 对接已有 Ceph | 多环境/多租户 |
下图展示了标准部署模式与外部集群模式的架构对比：
3.4 部署模式选择建议
- 新建项目，无历史包袱： 优先选择 标准部署模式，享受最完整的自动化运维能力。
- 已有生产级 Ceph 集群： 选择 外部集群模式，避免重复建设和数据迁移风险。
- 需要隔离多个存储集群（如开发/测试/生产）： 选择 多集群管理模式，但需注意 Operator 的资源消耗和网络规划。