#架构

#第 1 章：简介

Alauda Build of Rook-Ceph 是 Alauda Container Platform (ACP) 的云原生存储层。它作为 Kubernetes 原生系统运行，并通过 operator、自定义资源和 CSI 驱动程序提供持久化存储服务。

从应用的角度来看，该平台提供三种主要存储类型：

• 文件存储：为需要多个 pod 并发读写访问的工作负载提供共享文件系统语义（例如 RWX 场景）。
• 块存储：为需要专用卷的延迟敏感型或数据库类工作负载提供底层块设备。
• 对象存储：为非结构化数据、备份构件和数据平台集成提供兼容 S3 的对象访问。

Alauda Build of Rook-Ceph 集成了以下核心开源项目：

• Ceph：提供块、文件和对象能力的分布式存储引擎。
• Rook：用于部署和管理 Ceph 集群的 Kubernetes operator 框架。
• Ceph CSI Operator：管理 Ceph CSI 驱动程序组件及其生命周期的 operator。
• Ceph CSI：Kubernetes 用于 Ceph 支持卷的动态置备、连接/挂载和生命周期操作的 CSI 实现。

#第 2 章：架构概览

从较高层面来看，Alauda Build of Rook-Ceph 完全运行在 Alauda Container Platform 内部。

Alauda Build of Rook-Ceph 架构

Alauda Build of Rook-Ceph 使用故障域配置来确定数据副本如何分布在集群中。故障域表示一个物理边界，例如主机、机架或可用区，数据副本会分布在该边界内，以确保高可用性。Alauda Build of Rook-Ceph 会根据分配给存储节点的标签自动识别这些故障域。

#第 3 章：Operators

Alauda Build of Rook-Ceph 由以下两个 Operator Lifecycle Manager (OLM) operator bundle 组成，其中部署的 operator 将管理任务和自定义资源编码，从而可以轻松自动化任务和资源特征：

• acp-storage-operator
• rook-ceph-operator

管理员定义集群的期望最终状态，operator 确保集群处于该状态或向该状态靠近，同时尽可能减少管理员干预。

#Rook-Ceph operator

rook-ceph-operator 是 Alauda Build of Rook-Ceph 中用于 Ceph 的 operator。它支持 Ceph 存储系统作为 Kubernetes 管理的服务运行在 Alauda Container Platform 上。

rook-ceph-operator 容器会自动引导存储集群并监控存储守护进程，以维护集群运行状况。

#组件

rook-ceph-operator 管理以下 Ceph 守护进程组件：

• Mons：Ceph monitor（mons）维护集群元数据和仲裁。
• OSD：Object Storage Daemon（OSDs）存储和复制数据。
• Mgr：Ceph manager（mgr）提供指标和内部管理功能。
• RGW：RADOS Gateway（RGW）通过兼容 S3 的 API 提供对象存储访问。
• MDS：Metadata Server（MDS）为 CephFS 共享文件系统提供元数据服务。

#设计图

设计图展示了 rook-ceph-operator 如何将 Ceph 与 ACP 集成。

应用可以通过挂载块设备和共享文件系统，或使用对象存储 API，来使用此存储层。

#职责

rook-ceph-operator 负责引导和监控存储集群，具体职责如下：

• 自动配置存储组件。
• 启动、监控和管理 RADOS 集群的 Ceph monitor pod 和 Ceph OSD 守护进程。
• 初始化用于管理以下内容的 pod 和构件：
  • pool 自定义资源
  • 对象存储（S3）
  • 文件系统
• 监控 Ceph monitor 和 OSD 守护进程，以保持存储可用且运行状况良好。
• 部署和管理 monitor 放置，并在集群规模发生变化时更新 monitor 配置。
• 监视通过 API 服务请求的期望状态变更，并应用这些变更。
• 初始化 Ceph-CSI 驱动程序。
• 自动配置 Ceph-CSI，将 Ceph 存储挂载到应用 pod。

rook-ceph-operator 镜像包含生命周期管理所需的工具。它不会修改数据路径，也不会公开所有底层 Ceph 配置；placement group 和 CRUSH map 等高级 Ceph 构造仍保持抽象，从而提供更简单的运维模型。

#资源

operator 会为其在 rook-ceph 命名空间中创建的资源添加所有者引用。卸载期间，这些引用可确保同时删除关联资源，包括 ConfigMaps、Secrets、Services、Deployments 和 DaemonSets。

operator 会监视并协调以下自定义资源：

• CephCluster
• CephObjectStore
• CephFilesystem
• CephBlockPool

#生命周期

operator 管理以下 Ceph 和 CSI pod 的生命周期：

• Rook operator：
  • 一个 operator pod。
• RBD CSI Driver：
  • 两个由一个 deployment 管理的 provisioner pod。
  • 每个节点一个由 DaemonSet 管理的 plugin pod。
• CephFS CSI Driver：
  • 两个由一个 deployment 管理的 provisioner pod。
  • 每个节点一个由 DaemonSet 管理的 plugin pod。
• Monitors（mons）：
  • 三个 monitor pod，每个 pod 都有自己的 deployment。
  • 在 stretch 集群中有五个 monitor pod：arbiter 区域一个，每个数据区域两个。
• Manager（mgr）：
  • 标准 deployment 中的两个 manager pod。
• Object Storage Daemons（OSDs）：
  • 初始至少创建三个 OSD。
  • 随着集群容量扩展，会添加更多 OSD。
• Metadata Server（MDS）：
  • 两个 metadata server pod。
• RADOS Gateway（RGW）：
  • 至少两个 gateway pod。

#ACP storage operator

acp-storage-operator 是 ACP 专用 operator，负责协调 CephCluster 资源，并管理围绕运维、监控和故障排除的内置 ACP 存储集成。

#组件

acp-storage-operator 管理以下内置集成组件：

• 用于 CephCluster 的 Ceph 协调控制器。
• 两个 MutatingWebhookConfiguration 条目：
  • 一个用于 CephCluster
  • 一个用于 CephFilesystem

#设计图

acp-storage-operator 作为 ACP 中的控制平面 operator 运行，并通过 ACP 原生监控和运维资源扩展 Ceph 集群生命周期。

#职责

acp-storage-operator 执行以下职责：

• 监视并协调 CephCluster 资源。
• 通过变更 Webhook，在创建时修改 CephCluster 和 CephFilesystem 对象。
• 在变更期间初始化 ACP 专用默认值，包括 resources、placement 及相关运行时设置。
• 创建用于 ACP 所需 Ceph manager 功能的内置 .mgr pool。
• 创建并维护 ACP 内置 AlertRule 资源。
• 创建并维护 ACP 内置 MonitorDashboard 资源。
• 自动启用并维护 rook-ceph-tools pod。

#资源

acp-storage-operator 为每个协调的 CephCluster 创建并管理以下资源：

• 内置 Ceph .mgr pool。
• ACP 内置 AlertRule 对象。
• ACP 内置 MonitorDashboard 对象。
• rook-ceph-tools pod 及其相关运行时资源。

#生命周期

acp-storage-operator 在内部模式下遵循以下生命周期：

1. 引导阶段：operator deployment 启动，并为 CephCluster 和 CephFilesystem 注册控制器和变更准入 Webhook。
2. 准入阶段：收到创建请求时，Webhook 会在对象持久化之前注入 ACP 默认值（例如 resources 和 placement）。
3. 协调阶段：CephCluster 变为可用后，operator 会持续协调 ACP 内置资源，包括 .mgr pool、AlertRule、MonitorDashboard 和 rook-ceph-tools pod。
4. 清理阶段：删除 CephCluster 时，operator 会移除其为该集群创建的所有 ACP 管理资源。

#第 4 章：安装概览

本章介绍内部模式和外部模式下的安装流程。

#operator 安装

• OLM 为 ACP 内置存储集成安装 acp-storage-operator。
• OLM 从其软件包安装 rook-ceph-operator，并创建 operator deployment。
• 该 deployment 包含协调 CephCluster 和 Ceph 相关资源所需的控制组件。
• acp-storage-operator 为 CephCluster 和 CephFilesystem 对象注册变更准入 Webhook。
• 启动后，operator 开始监视 CRD，并准备存储使用所需的 CSI 组件。

#Ceph 集群创建概览

• 管理员创建 CephCluster 自定义资源。
• operator 使用该声明编排 Ceph 相关资源和 CSI 服务。
• 在内部模式下，acp-storage-operator 还会围绕同一个 CephCluster 协调 ACP 内置存储资源。
• 具体的协调路径因部署模式而异：内部模式或外部模式。

#CephCluster 创建

#内部模式

在内部模式下，存储守护进程运行在创建 CephCluster 的 ACP 集群中。

1. operator 在存储命名空间中接收 CephCluster。
2. acp-storage-operator 变更准入 Webhook 为 CephCluster 和 CephFilesystem 资源初始化 ACP 默认值（例如 resources 和 placement）。
3. rook-ceph-operator 初始化监控器仲裁，并创建管理器守护进程。
4. OSD 准备作业发现已配置的设备，然后创建 OSD deployment。
5. 为 RBD 和 CephFS 部署 Ceph CSI provisioner 和节点插件 pod。
6. acp-storage-operator 协调 ACP 内置资源，包括 .mgr pool、内置 AlertRule、内置 MonitorDashboard 以及 rook-ceph-tools pod。
7. StorageClass 对象通过 PVC 工作流变为可用于动态配置。
8. 集群运行状况和就绪状态会通过 CephCluster 状态持续报告。

#外部模式

在外部模式下，Ceph 数据平面运行在外部 provider 集群中，而 ACP 承载使用方的控制集成。

1. operator 在使用方 ACP 集群中安装并协调 CSI 组件。
2. 导入外部 Ceph 连接数据（例如监控器端点、集群标识符和客户端密钥）。
3. 以外部模式（external: true）协调 CephCluster，以表示远程 Ceph 后端。
4. 使用方集群中不会创建本地监控器或 OSD 守护进程。
5. RBD 和 CephFS CSI 驱动程序使用导入的连接信息，从外部 Ceph 集群配置和挂载卷。
6. 根据使用方组件和外部连接检查的结果协调状态和运行状况。

#第 5 章：升级概览

Alauda Build of Rook-Ceph 通过 Subscription、InstallPlan 和 ClusterServiceVersion（CSV）资源遵循由 OLM 管理的升级工作流。有关受支持的 operator 加数据平面操作步骤，请参阅升级。

当前 channel 中出现较新的 bundle 后，OLM 会创建 InstallPlan，执行过程取决于自动或手动批准策略。

在批准 InstallPlan 后，OLM 执行 CSV 协调：

• 安装新的 CSV。
• 将 operator Deployment 更新为新镜像并重新启动。
• 成功完成过渡检查后，替换旧 CSV。

在 4.4.1 及更高版本中，已安装的 CSV 为 Succeeded 后，平台会将唯一的 CSV relatedImages 条目（其 name 为 ceph）写入内部 CephCluster.spec.cephVersion.image。如果该镜像已经是当前运行的值，则不会滚动更新 Ceph 守护进程。外部模式集群不会接收本地 Ceph 镜像写入。在 4.4.0 中，平台不会写入该镜像；请按照升级中的说明使用 kubectl。

随后，operator 级别的协调会完成其余配置：

• operator 会验证并根据面向用户的 CR 重新应用期望状态。
• 检查 Ceph 和 CSI 资源，确保其配置与版本一致。
• 持续纠正偏差，直至集群状态报告运行状况良好且已收敛。