Rook部署——k8s集群中使用ceph
比起君子讷于言而敏于行，我更喜欢君子善于言且敏于行。
目录
1. CRD（CustomResourceDefinition）——抽象出“Ceph 资源”
1. 部署 Rook 控制面（CRD + Operator）
前言
想在k8s集群中使用ceph，应该怎么做呢？使用Rook
一、为什么选 Rook？
裸 Ceph 是给 2010 年代裸机/虚拟机环境设计的，Rook 是给 2020 年代 Kubernetes 时代而生的 Ceph。Rook 不是存储系统，它只是 Ceph 的自动化运维系统（Operator）。
Rook 只需要你：写 yaml 、 Apply、 让 Operator 自动 reconcile。然后所有组件自动出现、自动扩容、自动修复。
它的唯一作用：让 Ceph 能以 Kubernetes 原生方式运行、扩容、自愈，硬盘自动接管
Ceph = 真正存储
Rook = Ceph 的大脑 + 自动驾驶仪
K8s = 环境 + 编排
二、Rook 低层原理（必须理解的组件）
1. CRD（CustomResourceDefinition）——抽象出“Ceph 资源”
Rook 把 Ceph 的东西全部抽象成 Kubernetes API 对象：
| Ceph 组件 | Rook 的 CRD |
|---|---|
| 整个 Ceph 集群 | CephCluster |
| 存储池 | CephBlockPool |
| 文件系统 CephFS | CephFilesystem |
| OSD 存储设备 | CephCluster.storage.devices |
| Mgr / Mon | CephCluster.mgr / mon |
| RBD StorageClass | StorageClass |
| RGW/对象存储 | CephObjectStore |
Rook 让 Kubernetes 本身能够理解“Ceph 这个东西”。
2. Rook Operator（核心自动化大脑）
Operator 是一个永远处于 “observing → reconciling → fixing” 的控制回路：
CRD YAML 变化 → Operator 看到了 ↓ Operator 生成 Ceph 配置 / 命令 ↓ Operator 创建相应的 Pod、OSD、mon、mgr ↓ 确保状态达到你 YAML 要的样子
它会 一直监控：
-
Ceph 守护进程是否运行
-
MON quorum 是否健康
-
OSD 是否 down / out
-
新硬盘是否出现
-
节点是否加入/退出集群
你只写 YAML → 其它全部 Operator 负责。这就是 Kubernetes 的 operator 模式。
3. Ceph Daemons（真正干活的）
在容器里跑真正的 Ceph 服务：
| 组件 | 作用 |
|---|---|
| ceph-mon | 整个集群的脑，维护 map |
| ceph-mgr | Dashboard、Prometheus、Orchestrator 模块 |
| ceph-osd | 管 HDD/SSD（你的 8T/2T） |
| ceph-mds | CephFS 的 namespace server |
| ceph-rgw | S3 网关（可选） |
Rook 帮你管理它们，但它们本身就是原生 Ceph。
三、Rook 架构图
CRD：让 Kubernetes“知道”什么是 Ceph（像提供新 API）
Operator：看 YAML → 生成 Pod → 控制 Ceph（自动化运维系统）
Ceph 容器：真正的存储系统
四、 Rook 需要哪些 YAML（这是最重要的部分）
1. 部署 Rook 控制面（CRD + Operator）
这一步是所有集群通用的，不涉及磁盘。
通常有三个文件（只需 apply 一次）：
| 文件 | 作用 |
|---|---|
crds.yaml | 定义 CephCluster / CephBlockPool / CephFilesystem 等 CRD |
common.yaml | RBAC、namespace、service accounts |
operator.yaml | Operator 主体，负责启动大脑 |
📌 执行这 3 个文件后，集群不包含任何 Ceph，只是“准备好 Ceph 的大脑”
2. 部署 Ceph 集群（跟硬盘有关）
这是最核心的 cluster.yaml。这个文件明确告诉 Rook：
-
Ceph 要在哪里跑
-
要启用哪些模块
-
如何使用你的硬盘
-
有几个 MON
-
是否开启 dashboard
-
是否使用 SSD 作为 WAL/DB
📌 这个 YAML ＝ 整个 Ceph 的定义
OSD 出现与否、设备如何使用，都在这里。
3. 可选的（按需创建）
| YAML | 作用 |
|---|---|
CephFilesystem | 创建 CephFS，自动部署 MDS |
CephBlockPool | 创建 RBD 池 |
StorageClass | 给 K8s PVC 提供 Ceph RBD/FS 卷 |
CephObjectStore | S3 服务 |
CephObjectStoreUser | 创建 S3 用户 |
未来最常用的是：
-
CephFS（共享文件存储）
-
RBD（持久化块存储）
五、各个yaml的作用
| YAML | 属于 Rook 哪一层？ | 它控制什么？ | 什么时候 apply？ |
|---|---|---|---|
crds.yaml | k8s API | 定义 Ceph 的所有资源类型 | 第一次部署 Rook 时 |
common.yaml | RBAC | 权限、ServiceAccount、Namespace | 第一次部署 Rook 时 |
operator.yaml | Rook 大脑 | Operator 的 Pod & Controller | 第一次部署 Rook 时 |
cluster.yaml | 你的集群定义 | MON/OSD/MGR、磁盘分配、网络 | 有 HDD 时执行 |
filesystem.yaml | CephFS | 创建 MDS + Pool + FS | Ceph 集群 ready 后 |
block-pool.yaml | RBD | RBD 池（给 PVC 用） | 需要块存储时 |
storageclass.yaml | K8s SC | PVC 自动绑定 Ceph | 做持久化卷时 |
objectstore.yaml | RGW | Swift/S3 接口 | 做 S3 时 |
注意：cluster.yaml优先级最高。crds.yaml、common.yaml、operator.yaml只负责“让 Rook 自己跑起来”。Ceph 集群的实际配置永远以cluster.yaml 为准。所以首次run的时候可以直接用官方的模板
防踩坑提醒：
1. ubuntu16.04不要使用高版本的ceph，否则即使部署成功。也没办法使用pvc挂载到pod上使用。只能是手动的docker run一个低版本的ceph的pod，然后当做本地目录挂载到k8s的pod进行使用。
2. cluster.yaml里面的磁盘一定要一定一定不要写/dev/sdX！！！要写磁盘唯一的磁盘固件提供的 WWN（World Wide Name）定不要因为，如果你后续新增磁盘，重新扫描的时候这个/dev/sdX很有可能会发生变化。赌不起，一旦发生变化，所有盘的容量都是一样的，根本无法区分哪块是已经在集群里的，哪块是要新增的。
六、操作命令
# 安装调试工具（非必须但推荐）
sudo apt install -y lvm2 ceph-common jq
#下载适合k8s1.21的版本，主要是用examples
cd /home/ubuntu
git clone --single-branch --branch v1.11.9 https://github.com/rook/rook.git
cd rook/deploy/examples
# 部署 CRDs + common + operator（上一步已cd,这一步用的是需要用examples里面的yaml）
kubectl create namespace rook-ceph
kubectl apply -f crds.yaml -f common.yaml -f operator.yaml
# 验证，有点儿耐心，等一下，拉取镜像需要时间。这一步之后，集群里已经“认识 Ceph 这个东西”了。
kubectl -n rook-ceph get pods
#准备好适合自己的cluster.yaml
kubectl apply -f cluster.yaml
#这个镜像总是无法自动拉取，不清楚为什么，可以先手动拉一下
sudo docker pull rook/ceph:v1.11.9
#这次应该能看到：rook-ceph-mon-* rook-ceph-mgr-* ，耐心等一等
kubectl -n rook-ceph get pods
# 验证
kubectl -n rook-ceph get pods -o wide
# 看看dashboard，UI页面
kubectl -n rook-ceph get svc | grep dashboard
kubectl -n rook-ceph get pod -l app=rook-ceph-mgr -o wide
#让系统自动分配一个 30000-32767 端口
kubectl -n rook-ceph patch svc rook-ceph-mgr-dashboard -p '{"spec":{"type":"NodePort"}}'
#查看一下分到了哪个端口，进行ip+端口访问即可
kubectl -n rook-ceph get svc rook-ceph-mgr-dashboard
七、cluster.yaml模板详细解释
#################################################################################################################
# 定义rook-ceph生产集群的配置设置
# 所有具有可用原始设备的节点都将用于Ceph集群。在此示例中至少需要三个节点
# 有关可用的存储设置详细信息，请参阅文档
# 例如，创建集群：
# kubectl create -f crds.yaml -f common.yaml -f operator.yaml
# kubectl create -f cluster.yaml
#################################################################################################################
# API版本和资源类型定义
apiVersion: ceph.rook.io/v1 # 使用Ceph Rook API的v1版本
kind: CephCluster # 资源类型为Ceph集群
metadata:
name: rook-ceph # 集群名称
namespace: rook-ceph # 命名空间:集群（集群将在rook-ceph命名空间中运行）
spec:
# Ceph版本配置
cephVersion:
# 用于启动Ceph守护进程Pod（mon、mgr、osd、mds、rgw）的容器镜像
# v16是Pacific版本，v17是Quincy版本
# 建议：在生产环境中，使用特定的版本标签而不是通用的v17标志
# 因为v17会拉取最新版本，可能导致集群内运行不同版本
image: quay.io/ceph/ceph:v17.2.6 # 指定具体的Ceph镜像版本，ubuntu16.04不要用这个版本，建议是低一些的版本。踩坑，17版本是用不起来的。
# 是否允许不支持的Ceph版本。当前支持'pacific'和'quincy'
# 未来版本如'reef'（v18）需要将此设置为'true'
# 生产环境中不要设置为true
allowUnsupported: false
# 主机上配置文件持久化的路径。必须指定
# 重要：如果重新安装集群，请确保从每个主机删除此目录，否则新集群上的mon将无法启动
dataDirHostPath: /var/lib/rook
# 即使检查失败，是否继续升级
skipUpgradeChecks: false
# 升级期间如果PG不干净是否继续
continueUpgradeAfterChecksEvenIfNotHealthy: false
# 定义在升级或重启前，operator等待OSD健康的超时时间（分钟）
waitTimeoutForHealthyOSDInMinutes: 10
# Monitor配置
mon:
count: 3 # 设置要启动的mon数量。一般建议为3个
allowMultiplePerNode: false # mon是否允许在同一节点上。生产环境应为false
# Manager配置
mgr:
count: 2 # 需要更高可用性时增加到2，一个活跃一个备用
allowMultiplePerNode: false
modules: # 启用PG自动扩缩容模块
- name: pg_autoscaler
enabled: true
# Ceph仪表板配置
dashboard:
enabled: true # 启用Ceph仪表板
ssl: true # 使用SSL提供仪表板服务
# 监控配置
monitoring:
enabled: false # 是否启用Prometheus告警
metricsDisabled: false # 是否禁用Ceph报告的指标
# 网络配置
network:
connections:
encryption:
enabled: false # 是否启用网络传输加密
compression:
enabled: false # 是否启用网络传输压缩
requireMsgr2: false # 是否要求使用msgr2协议通信
# 崩溃收集器配置
crashCollector:
disable: false # 启用Ceph守护进程崩溃收集
# 日志收集器配置
logCollector:
enabled: true # 启用日志收集
periodicity: daily # 日志轮转周期：每小时、每天、每周或每月
maxLogSize: 500M # 最大日志大小
# 清理策略配置
cleanupPolicy:
confirmation: "" # 集群销毁时的数据清理确认
sanitizeDisks: # 磁盘清理设置
method: quick # 清理方法：快速或完全
dataSource: zero # 数据源：零或随机
iteration: 1 # 覆盖迭代次数
allowUninstallWithVolumes: false # 是否允许在有PV时卸载
# 注解配置（此处为空）
annotations:
# 标签配置（此处为空）
labels:
# 资源限制配置（此处为空）
resources:
# 优先级类名称配置
priorityClassNames:
mon: system-node-critical # mon使用节点关键优先级
osd: system-node-critical # osd使用节点关键优先级
mgr: system-cluster-critical # mgr使用集群关键优先级
# 存储配置
storage:
useAllNodes: true # 使用所有节点
useAllDevices: true # 使用所有设备
config: # 存储配置
# 可配置CRUSH根、元数据设备、数据库大小等
# 中断管理配置
disruptionManagement:
managePodBudgets: true # 管理Pod中断预算
osdMaintenanceTimeout: 30 # OSD维护超时时间（分钟）
pgHealthCheckTimeout: 0 # PG健康检查超时时间
# 健康检查配置
healthCheck:
daemonHealth: # 守护进程健康检查
mon:
disabled: false
interval: 45s
osd:
disabled: false
interval: 60s
status:
disabled: false
interval: 60s
livenessProbe: # 存活探针配置
mon:
disabled: false
mgr:
disabled: false
osd:
disabled: false
startupProbe: # 启动探针配置
mon:
disabled: false
mgr:
disabled: false
osd:
disabled: false总结
重点还是搞清楚yaml，基本上就不会有什么问题。后续我会再整理cluster.yaml的详细内容分析，彻底吃透它。
更多推荐
15
0- 0
已为社区贡献9条内容
所有评论(0)