4. Rook Ceph 架构回顾：Rook Operator、Ceph Daemon 的部署模型
在构建容量基线之前，必须精确理解 Rook 与 Ceph 的协同部署模型。Rook 并非简单地“在 Kubernetes 上运行 Ceph”，而是通过 Operator 模式将 Ceph 的完整生命周期管理（部署、配置、扩缩容、升级、故障恢复）抽象为 Kubernetes 原生资源。本章节聚焦于 Rook Operator 与五大核心 Ceph Daemon（MON、OSD、MGR、MDS、RGW）的部署拓扑与职责边界。
4.1 Rook Operator：集群的“大脑”
Rook Operator 是一个运行在 Kubernetes 上的控制器，它监听自定义资源（CRD）的变化，并驱动集群状态向期望状态收敛。其部署模型具有以下特征：
- 单实例/多副本：通常以 Deployment 形式部署 1 个副本（生产环境建议 2 个副本实现高可用，但仅 Leader 执行协调）。
- 命名空间隔离：Operator 自身运行在
rook-ceph命名空间，而 Ceph 集群资源可跨命名空间管理。 - 权限模型：需要 ClusterRole 以管理节点、PVC、Pod、Service 等资源。
关键职责：
- 处理
CephClusterCR 的创建/更新/删除。 - 自动生成并更新 Ceph 配置文件（ceph.conf）。
- 监控 Daemon 健康状态，触发自动修复（如 MON 仲裁修复、OSD 重建）。
- 协调版本升级流程（确保 Daemon 按正确顺序滚动更新）。
4.2 Ceph Daemon 部署模型详解
每个 Ceph Daemon 在 Kubernetes 中的部署方式不同，直接影响资源分配、网络模型与故障域设计。下表总结了五大 Daemon 的部署模型差异：
| Daemon | K8s 资源类型 | 部署策略 | 网络模式 | 存储依赖 | 故障域 |
|---|---|---|---|---|---|
| MON | Deployment / StatefulSet | 反亲和性分布，奇数个（3/5/7） | ClusterIP + 主机网络（可选） | PVC 或 hostPath（存储数据） | 节点/可用区 |
| OSD | DaemonSet（推荐） | 每个存储节点一个 Pod，自动发现设备 | 主机网络（必须） | 直接挂载宿主机磁盘/分区 | 节点/磁盘 |
| MGR | Deployment | 2 副本（Active/Standby） | ClusterIP | 无状态（仅缓存） | 节点 |
| MDS | Deployment / StatefulSet | 根据 CephFS 数量动态扩缩 | ClusterIP | 依赖 MON/OSD 提供元数据 | 节点 |
| RGW | Deployment + Service | 多副本水平扩展，Ingress 暴露 | ClusterIP / LoadBalancer | 无状态（依赖 OSD 存储桶） | 节点 |
版本漂移校准要点： 在版本升级过程中，MON 和 OSD 的滚动更新顺序由 Operator 严格控制。MON 必须全部升级完成并形成仲裁后，OSD 才开始逐个升级。MGR 的 Active/Standby 切换可能导致短暂的指标采集中断，但不影响数据面。
4.3 核心 Daemon 职责与交互
4.3.1 MON（Monitor）
MON 维护集群的 Cluster Map（包括 MON Map、OSD Map、PG Map、MGR Map、CRUSH Map）。所有客户端和 OSD 通过 MON 获取集群拓扑。部署要求：
- 必须部署奇数个（通常 3 个），形成 Paxos 仲裁。
- 每个 MON 需要独立的 PVC 存储数据（约 10-50 GB）。
- 网络延迟敏感：节点间 RTT 建议 < 10ms。
4.3.2 OSD（Object Storage Daemon）
OSD 是数据面的核心，每个 OSD 对应一个物理磁盘或分区。Rook 通过 storage.nodes 或 storage.deviceFilter 自动发现设备。部署模型关键点：
- 以 DaemonSet 方式运行，确保每个存储节点自动启动 OSD Pod。
- 必须使用 主机网络（
hostNetwork: true），避免 NAT 导致的性能损失。 - OSD 的 CRUSH 权重由磁盘容量自动计算，容量规划时需关注
osd crush weight与物理容量的映射。
4.3.3 MGR（Manager）
MGR 提供监控指标、Dashboard、REST API 和自动化均衡功能。部署模型：
- 默认 2 副本，Active 实例处理请求，Standby 实例热备。
- 无状态设计，重启后从 MON 和 OSD 重新收集数据。
- MGR 的
pg_autoscaler模块在容量规划中自动调整 PG 数量，但基线构建时建议手动锁定 PG 分布。
4.3.4 MDS（Metadata Server）
MDS 为 CephFS 提供元数据缓存服务。部署模型：
- 每个 CephFS 文件系统至少需要 1 个 Active MDS，可配置多个 Standby 实现故障切换。
- MDS 内存消耗与文件数量正相关，容量规划时需预留足够内存（建议每百万文件 4 GB）。
4.3.5 RGW（RADOS Gateway）
RGW 提供 S3/Swift 兼容的对象存储接口。部署模型：
- 无状态 Deployment，可通过 HPA 根据 CPU/请求量自动扩缩。
- 前端通常挂载 Ingress 或 LoadBalancer Service。
- RGW 的
rgw_bucket_default_quota和rgw_user_default_quota是容量规划中重要的配额控制参数。
4.4 部署模型对容量规划的影响
理解上述部署模型后，容量规划基线构建需关注以下映射关系：
| Daemon | 容量规划关注点 | 版本漂移风险 |
|---|---|---|
| MON | 存储数据量小但 I/O 敏感；仲裁节点数影响故障容忍度 | 版本升级期间仲裁可能临时降级 |
| OSD | 磁盘容量、IOPS、网络带宽；CRUSH 权重与物理容量对齐 | OSD 版本不匹配可能导致 PG 无法正常 Peering |
| MGR | 内存与 CPU 用于指标聚合；无持久化存储 | 版本升级时 Active/Standby 切换可能丢失瞬时指标 |
| MDS | 内存与文件数线性相关；元数据性能影响 CephFS 延迟 | MDS 版本不兼容可能导致客户端挂载失败 |
| RGW | 请求吞吐量、对象大小分布；配额控制 | RGW 版本差异可能导致 S3 接口行为不一致 |
版本漂移校准警告： 在混合版本集群中（例如升级过程中），OSD 与 MON 之间的通信协议可能因版本差异导致兼容性问题。Rook 通过
skipUpgradeChecks 参数允许跳过部分检查，但生产环境严禁使用。基线构建时必须记录每个 Daemon 的精确版本号，并与 CephCluster CR 中的 version 字段对齐。