从Kubernetes视角理解Ceph架构：一份为K8s工程师准备的Ceph入门指南

对于熟悉Kubernetes但对Ceph不太了解的工程师来说，理解Ceph的架构可能会有一定难度。实际上，Ceph和Kubernetes在设计理念上有许多相似之处。本文将以Kubernetes工程师熟悉的视角，帮助大家理解Ceph的架构组成和工作机制。

引言：为什么K8s工程师应该了解Ceph？

在云原生生态系统中，Kubernetes负责容器编排和应用调度，而Ceph则提供了强大的分布式存储能力。两者结合可以为容器化应用提供完整的基础设施解决方案。理解Ceph的架构有助于：

1. 更好地为Kubernetes集群配置持久化存储
2. 排查存储相关的问题
3. 优化应用的存储性能
4. 设计高可用的云原生基础设施

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算法决定了数据应该如何分布在整个集群中，它考虑了：

• 数据副本的数量
• 故障域隔离
• 集群拓扑结构
• 负载均衡

管理器：MGR vs K8s Controller Manager

Kubernetes	Ceph	功能对比
Controller Manager	MGR (Manager)	集群管理和控制循环
Various Controllers	Various Modules	特定功能的控制器

在Kubernetes中，Controller Manager运行着各种控制器，维护着集群期望的状态。同样，Ceph的MGR也提供了类似的管理功能。

MGR的主要职责：

• 提供Web管理界面（Dashboard）
• 收集和暴露集群指标（与Prometheus集成）
• 管理集群的各种模块
• 提供RESTful API接口

存储接口：CSI vs Ceph Client

Kubernetes	Ceph	功能对比
CSI Driver	Ceph Client	存储接口抽象
StorageClass	Pool	存储类别定义
PV/PVC	CephFS/RBD	存储资源分配

在Kubernetes中，通过CSI（Container Storage Interface）驱动程序来与各种存储系统对接。同样，Ceph也提供了客户端库和工具来与应用程序交互。

Ceph核心概念详解

RADOS：Ceph的底层存储层

RADOS（Reliable Autonomic Distributed Object Store）是Ceph的核心存储层，相当于Kubernetes的etcd存储层，但更加复杂和功能丰富。

RADOS的特点：

• 可靠性：通过多副本或纠删码保证数据不丢失
• 自治性：自我管理和自我修复
• 分布式：数据分布在整个集群中
• 对象存储：以对象为单位存储数据

存储池（Pool）vs 命名空间（Namespace）

在Kubernetes中，命名空间用于组织和隔离资源。在Ceph中，存储池（Pool）扮演着类似的角色。正如你所说，Pool对应的则是Namespace。

存储池的特性：

• 定义数据的副本数或纠删码策略
• 可以设置配额和访问控制
• 不同的存储池可以有不同的性能特征

就像在Kubernetes中，不同命名空间中的资源彼此隔离一样，在Ceph中，不同存储池中的数据也相互独立，拥有各自的配置和策略。

Placement Group（PG）vs Pod

在Kubernetes中，Pod是最小的部署单元，包含了相关的容器。正如你指出的，Pod对应的是PG。在Ceph中，Placement Group（PG）是数据分布和管理的基本单元。

PG的作用：

• 将大量的对象组织成更易管理的组
• 提供数据分布和复制的逻辑边界
• 加速集群状态的计算和恢复

就像Pod是一组相关容器的封装一样，PG是一组相关对象的逻辑集合，它们共同参与数据分布和复制策略。

Ceph服务类型

就像Kubernetes提供不同类型的服务（Deployment、StatefulSet、DaemonSet等），Ceph也提供了多种存储服务：

1. CephFS：类似网络文件系统（NFS），提供文件存储接口
2. RBD（RADOS Block Device）：提供块存储，类似于云服务商的云硬盘
3. RGW（RADOS Gateway）：提供对象存储接口，兼容AWS S3和OpenStack Swift

Ceph数据流动与K8s Pod调度对比

K8s Pod调度流程回顾

1. 用户通过kubectl创建Deployment
2. API Server接收请求并存储到etcd
3. Scheduler监控未调度的Pod
4. Scheduler根据策略选择合适的节点
5. Kubelet在目标节点上启动Pod

Ceph数据写入流程

1. 客户端需要存储一个对象
2. 客户端连接MON获取集群地图
3. 客户端使用CRUSH算法计算对象应该存储在哪里
4. 客户端直接与对应的OSD通信存储对象
5. 主OSD负责将副本同步到其他OSD

这种设计的优势在于：

• 去中心化，没有单点瓶颈
• 客户端可以直接与OSD通信，减少延迟
• 数据分布算法透明且可控

高可用性实现对比

K8s高可用

• 多Master节点
• 多etcd节点
• 多副本应用部署

Ceph高可用

• 多MON节点（奇数个）
• 多OSD节点
• 多副本数据存储
• 多MGR节点

故障处理机制对比

K8s故障恢复

• Controller Manager检测到Pod故障
• Scheduler重新调度Pod到健康节点
• Kubelet在新节点上启动Pod

Ceph故障恢复

• MON检测到OSD故障
• CRUSH算法重新计算数据分布
• 健康OSD自动恢复丢失的数据副本

总结

通过将Ceph架构与熟悉的Kubernetes架构进行对比，我们可以更容易地理解Ceph的工作原理。两者在设计理念上有很多相似之处，都采用了分布式、去中心化的架构思想，都注重高可用性和自我修复能力。

对于Kubernetes工程师而言，掌握Ceph的基本概念和架构有助于：

• 更好地为K8s应用设计存储方案
• 快速定位和解决存储相关问题
• 构建更加健壮的云原生基础设施

希望本文能够帮助熟悉Kubernetes的读者更快地理解和掌握Ceph的核心概念。

参考资料

1. Ceph官方文档
2. Kubernetes官方文档
3. Ceph架构详解
4. Kubernetes架构指南