Rook Ceph 基础架构回顾：Rook Operator、Ceph 集群组件与 CRD 资源模型
在构建存储变更门禁流水线之前，必须深入理解 Rook Ceph 的控制面与数据面架构。Rook 并非简单地封装 Ceph 容器，而是通过 Kubernetes Operator 模式将 Ceph 的完整生命周期管理抽象为声明式资源模型。本节将拆解 Rook Operator 的协调逻辑、Ceph 核心守护进程的职责，以及支撑自动化变更的 CRD 资源体系。
2.1 Rook Operator：存储集群的自动化大脑
Rook Operator 是一个运行在 Kubernetes 上的自定义控制器，它持续监听 CephCluster、CephBlockPool、CephFilesystem 等自定义资源（CR）的变化，并将期望状态转换为实际的 Ceph 守护进程部署与配置。Operator 的核心协调循环（Reconciliation Loop）包含以下关键步骤：
- 资源监听：通过 Informer 机制监听 CR 对象的创建、更新、删除事件。
- 状态校验：对比当前集群状态与 CR 中声明的期望状态（如副本数、存储节点标签、网络配置）。
- 编排执行：调用 Ceph 管理命令（ceph orch、ceph mon、ceph osd）或直接操作 Kubernetes API 创建/更新 Deployment、Service、ConfigMap。
- 状态上报：将 Ceph 集群的健康状态、OSD 数量、MON 仲裁等信息写回 CR 的 status 字段。
2.2 Ceph 集群核心组件与职责
Ceph 存储集群由多个守护进程组成，每个组件在 Rook 中都以独立的 Kubernetes 工作负载形式运行。下表总结了各组件的功能、Rook 中的部署形态以及变更门禁关注点：
| 组件 | 全称 | 核心职责 | Rook 部署形态 | 变更门禁关注点 |
|---|---|---|---|---|
| MON | Monitor | 维护集群映射（Cluster Map）、提供仲裁（Quorum）、管理认证密钥 | Deployment + PVC | MON 数量必须为奇数；变更 IP 或端口需滚动重启 |
| OSD | Object Storage Daemon | 管理物理磁盘、处理数据读写、执行数据再平衡 | Deployment（或 DaemonSet 模式） | 磁盘更换、OSD 权重调整、故障域变更影响数据分布 |
| MGR | Manager | 提供集群指标、Dashboard、RESTful API、模块扩展 | Deployment | MGR 模块启停（如 pg_autoscaler、balancer）影响集群行为 |
| MDS | Metadata Server | 管理 CephFS 的元数据（目录结构、文件属性） | Deployment | 活跃/备用 MDS 数量、缓存大小影响文件系统性能 |
| RGW | RADOS Gateway | 提供 S3/Swift 兼容的对象存储接口 | Deployment + Service/Ingress | 多站点同步、桶策略、TLS 证书变更 |
2.3 CRD 资源模型：声明式存储管理
Rook 定义了一组 Kubernetes CRD（Custom Resource Definition），将 Ceph 的配置抽象为 Kubernetes 原生对象。流水线变更门禁的核心操作对象就是这些 CR 的 spec 字段。以下是 Rook Ceph 中最关键的 CRD 及其用途：
- CephCluster：集群级配置，包括 MON 数量、OSD 存储配置、网络设置（public/cluster network）、Dashboard 开关。
- CephBlockPool：RBD 块存储池，控制副本数、PG 数量、故障域（failure domain）、压缩算法。
- CephFilesystem：CephFS 文件系统，关联 MDS 实例数、元数据池与数据池配置。
- CephObjectStore：RGW 对象存储，定义网关实例数、端口、多站点配置。
- CephClient：客户端认证管理，用于生成 Kubernetes Secret 中的 keyring。
2.4 Rook Ceph 架构总览
下图展示了 Rook Operator 与 Ceph 组件在 Kubernetes 集群中的交互关系，以及 CRD 如何驱动整个存储系统的声明式管理：
2.5 CRD 资源模型与变更门禁的映射
在自动化流水线中，每一次存储变更最终都体现为对 CR 对象的 spec 字段的修改。下表列出了常见变更场景与对应的 CRD 字段，以及门禁策略建议：
| 变更场景 | 目标 CRD | 关键字段 | 门禁策略 |
|---|---|---|---|
| 调整副本数 | CephBlockPool | spec.replication.size | 自动门禁：校验新副本数 ≥ 2，且不超过 OSD 故障域数量 |
| 修改 PG 数量 | CephBlockPool | spec.pgCount | 人工门禁：PG 调整影响数据分布，需确认集群负载窗口 |
| 启用/禁用 Balancer | CephCluster | spec.cephConfig.mgr_modules | 自动门禁：仅允许在非业务高峰期触发 |
| 更换 OSD 磁盘 | CephCluster | spec.storage.nodes[].devices | 人工门禁：需确认磁盘替换后的数据再平衡计划 |
| 修改 MON 数量 | CephCluster | spec.mon.count | 人工门禁：必须保持奇数，且需滚动重启 MON |
| 调整 MDS 缓存 | CephFilesystem | spec.metadataServer.resources | 自动门禁：校验资源上限不超过节点可分配资源 |
2.6 组件间通信与数据流
理解 Ceph 组件间的通信模式对于诊断变更影响至关重要。下图展示了客户端与 Ceph 集群之间的数据读写路径，以及 MON 在其中的仲裁角色：