Rook Operator 架构:设计模式、CRD 资源定义与生命周期管理

Rook 是运行在 Kubernetes 之上的云原生存储编排器,其核心是 Rook Operator。Operator 模式将运维人员对 Ceph 集群的管理知识编码为软件,自动完成部署、配置、扩缩容、升级和故障恢复。本章深入剖析 Rook Operator 的架构设计、CRD 资源模型以及 Operator 的生命周期管理机制。

2.1 Rook Operator 设计模式

Rook 严格遵循 Kubernetes Operator 模式,该模式由 CoreOS 提出,核心思想是利用 Kubernetes 的控制器循环(Control Loop)来管理自定义资源。Rook Operator 由以下关键组件构成:

组件 角色 说明
Operator 二进制 控制循环引擎 以 Deployment 形式运行在 rook-ceph 命名空间中,监听 CRD 变化并执行调和逻辑。
CRD 定义 资源模型 扩展 Kubernetes API,定义 CephCluster、CephBlockPool、CephFilesystem 等存储资源。
调和循环 (Reconcile Loop) 状态机驱动 对比当前状态与期望状态,通过创建/更新/删除 Kubernetes 原生资源(Deployment、Service、ConfigMap)来驱动集群变化。
Agent (已弃用) 节点级操作 早期版本通过 DaemonSet 在每个节点执行存储挂载、设备发现等操作;自 Rook v1.6 起,Agent 功能被 CSI 驱动和 ceph-volume 替代。
Discover Daemon 设备发现 以 DaemonSet 运行,检测节点上未使用的原始块设备,并上报给 Operator 用于 OSD 部署。
设计要点: Rook Operator 采用“单一 Operator + 多个 CRD”的架构,而非为每种资源部署独立 Operator。这种设计降低了运维复杂度,并确保所有资源的状态调和在同一个控制循环中顺序执行,避免资源竞争。
Rook Operator 架构与调和循环 Rook Operator 架构与调和循环 Kubernetes API Server CephCluster CRD CephBlockPool CRD CephFilesystem CRD CephNFS CRD Rook Operator (Deployment: rook-ceph-operator) Deployment / StatefulSet Service / EndpointSlice ConfigMap / Secret PersistentVolumeClaim Watch / List 调和循环流程: 1. Operator 通过 Informer 监听 CRD 事件 → 2. 触发 Reconcile 函数 → 3. 对比当前状态与 CRD spec → 4. 创建/更新/删除 K8s 原生资源 → 5. 更新 CRD status

2.2 CRD 资源定义

Rook 通过自定义资源定义(CRD)将 Ceph 存储组件抽象为 Kubernetes 原生资源。每个 CRD 对应一个 Ceph 组件或存储池类型,用户通过 YAML 清单声明期望状态。

2.2.1 核心 CRD 清单

CRD 名称 API 版本 (示例) 管理组件 关键 Spec 字段
CephCluster ceph.rook.io/v1 MON、MGR、OSD、MDS mon.count, storage.nodes, network.hostNetwork
CephBlockPool ceph.rook.io/v1 RBD 存储池 replicated.size, erasureCoded, deviceClass
CephFilesystem ceph.rook.io/v1 CephFS 文件系统 metadataPool, dataPools, metadataServer.activeCount
CephNFS ceph.rook.io/v1 NFS-Ganesha 网关 server.active, exports, rados
CephObjectStore ceph.rook.io/v1 RGW 对象网关 gateway.instances, dataPool, metadataPool
CephClient ceph.rook.io/v1 客户端认证 caps, name

2.2.2 CRD 资源示例:CephCluster

以下是一个最小化的 CephCluster 定义,展示了如何声明一个 3 节点、3 副本的 Ceph 集群:

apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v18.2.0
  mon:
    count: 3
    allowMultiplePerNode: false
  storage:
    nodes:
    - name: node-1
      devices:
      - name: /dev/sdb
    - name: node-2
      devices:
      - name: /dev/sdb
    - name: node-3
      devices:
      - name: /dev/sdb
  network:
    hostNetwork: true
  dashboard:
    enabled: true
    ssl: true
设计原则: CRD 的 Spec 是“期望状态”,Operator 负责将其转换为 Ceph 集群的“实际状态”。用户不应直接通过 ceph 命令行修改集群配置,而应通过更新 CRD 资源来触发 Operator 的调和动作,确保声明式运维的一致性。

2.3 Operator 生命周期管理

Rook Operator 的生命周期管理涵盖从部署、运行、升级到故障恢复的全过程。Kubernetes 自身的控制器(Deployment、DaemonSet)负责 Operator 进程的存活,而 Operator 内部则管理 Ceph 集群组件的生命周期。

2.3.1 生命周期阶段

  1. 部署阶段: 通过 kubectl apply -f deploy/examples/operator.yaml 创建 Operator Deployment。Operator 启动后,首先注册 CRD 并启动 Informer 监听。
  2. 初始化阶段: 当第一个 CephCluster CR 被创建时,Operator 执行集群引导:部署 MON、生成初始密钥、创建 MGR 和 OSD。
  3. 运行阶段: Operator 持续监听 CRD 和集群状态,执行周期性健康检查(如 MON 仲裁、OSD 状态、PG 分布),并自动修复异常。
  4. 升级阶段: 用户更新 CephCluster CR 中的 cephVersion.image 字段,Operator 按顺序滚动升级 MON → MGR → OSD → MDS/RGW,确保服务不中断。
  5. 缩扩容阶段: 修改 mon.count 或 storage.nodes 字段,Operator 自动添加或移除 MON/OSD 实例。
  6. 故障恢复阶段: 当节点宕机或 OSD 故障时,Operator 检测到状态变化,自动触发 OSD 替换、PG 回填或 MON 重建。

2.3.2 升级流程示例

Rook Operator 的升级流程是生命周期管理的核心能力之一,以下表格展示了升级过程中的关键步骤和 Operator 的行为:

步骤 用户操作 Operator 行为 集群状态
1 更新 CephCluster spec.cephVersion.image 检测到镜像变更,设置集群状态为 "Upgrading" 健康,开始升级
2 无 滚动升级 MON:逐个更新 MON Deployment 镜像,等待新 MON 加入仲裁 MON 仲裁短暂降级,但可服务
3 无 升级 MGR:更新 MGR Deployment,等待 MGR 就绪 MGR 短暂不可用,不影响数据面
4 无 升级 OSD:逐个标记 OSD out,等待 PG 回填完成,然后更新 OSD 镜像并重新加入 集群处于降级状态,但数据完整
5 无 升级 MDS/RGW:更新对应的 Deployment,确保服务不中断 健康,升级完成
Rook Operator 生命周期状态机 Rook Operator 生命周期状态机 部署 初始化 运行 升级 故障恢复 缩扩容 持续调和循环 关键设计: 所有状态转换均由 CRD Spec 变更或集群事件触发,Operator 通过调和循环确保集群始终向期望状态收敛。

2.4 关键设计考量

  • 幂等性: Operator 的调和逻辑必须是幂等的,即使同一事件被多次触发,最终状态也应一致。Rook 通过检查资源是否存在、状态是否匹配来避免重复操作。
  • 优雅降级: 当 Operator 自身故障时,已运行的 Ceph 集群不受影响,但无法响应 CRD 变更。Kubernetes Deployment 控制器会自动重启 Operator Pod。
  • 版本兼容: Rook Operator 与 Ceph 版本之间存在兼容性矩阵。升级 Operator 前需查阅官方文档,确保 CRD 版本与 Ceph 版本匹配。
  • 资源隔离: Operator 通过 RBAC 限制自身权限,仅能操作 rook-ceph 命名空间内的资源,避免影响集群中其他工作负载。
生产建议: 在生产环境中,建议为 Rook Operator 设置资源请求和限制(CPU/Memory),并配置 PodDisruptionBudget 防止 Operator 在集群维护期间被全部驱逐。同时,开启 Operator 的详细日志级别(--log-level=DEBUG)有助于排查调和循环中的异常行为。