引言：为什么 K8s 工程师应该了解 Ceph？
对于熟悉 Kubernetes 但对 Ceph 不太了解的工程师来说，理解 Ceph 的架构可能会有一定难度。实际上，Ceph 和 Kubernetes 在设计理念上有许多相似之处。本文将以 Kubernetes 工程师熟悉的视角，帮助大家理解 Ceph 的架构组成和工作机制。
Ceph 与 Kubernetes 架构对比
我们可以将 Ceph 的组件与 Kubernetes 的组件进行类比，从而更容易理解它们的功能和作用。
控制平面：MON vs Master/API Server
| Kubernetes | Ceph | 功能对比 |
|---|---|---|
| Master Node | MON (Monitor) | 集群状态管理和协调 |
| API Server | MON (Monitor) | 提供集群状态查询接口 |
| etcd | MON (Monitor) | 存储集群状态信息 |
在 Kubernetes 中，Master 节点负责整个集群的管理和协调工作，维护着集群的状态。类似地，在 Ceph 中，MON（Monitor）承担着相似的责任。
MON 的主要职责：
- 维护集群的全局状态图（Cluster Map）
- 协调集群成员之间的通信
- 提供集群状态查询接口
- 管理认证和授权信息
就像 Kubernetes 需要至少一个 API Server 来提供服务一样，Ceph 也需要至少一个 MON 节点才能正常运行。但在生产环境中，通常会部署奇数个 MON 节点（3 或 5 个）以实现高可用性。
工作节点：OSD vs Worker Node
| Kubernetes | Ceph | 功能对比 |
|---|---|---|
| Worker Node | OSD (Object Storage Daemon) | 实际的工作负载执行 |
| Namespace | Pool | 资源组织和隔离 |
| Pod | PG (Placement Group) | 工作单元的逻辑分组 |
在 Kubernetes 中，Worker 节点负责运行 Pod，而在 Ceph 中，OSD 节点负责存储实际的数据。
OSD 的主要职责：
- 存储实际的数据对象
- 处理数据复制和恢复
- 执行数据平衡和清理操作
- 向 MON 报告状态信息
就像 Kubernetes 集群可以有多个 Worker 节点一样，Ceph 集群也可以有多个 OSD 节点。每个 OSD 节点通常对应一个物理磁盘或分区。
调度器：CRUSH vs K8s Scheduler
在 Kubernetes 中，Scheduler 负责将 Pod 调度到合适的节点上运行。而在 Ceph 中，虽然没有独立的调度器组件，但其核心算法 CRUSH（Controlled Replication Under Scalable Hashing）起到了类似的调度作用。
CRUSH 算法决定了数据应该如何分布在整个集群中，它考虑了：
- 数据副本的数量
- 故障域隔离
- 集群拓扑结构
- 负载均衡
