写在开篇
“上一次，我发了一篇：《理论篇：让我们一起鲁克鲁克——rook（开源存储编排）》。这次，来一篇实战，使用rook在k8s上把ceph集群搞起来。后续，还会陆续分享如何对接k8s（作为k8s的后端存储）、以及分享一些在生产上的实践经验。
”
环境规划
| 主机名 | IP | 角色 | 数据磁盘 |
| k8s-a-master | 192.168.11.10 | k8s master | |
| k8s-a-node01 | 192.168.11.11 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node02 | 192.168.11.12 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node03 | 192.168.11.13 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node04 | 192.168.11.14 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node05 | 192.168.11.15 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node06 | 192.168.11.16 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node07 | 192.168.11.17 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node08 | 192.168.11.18 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node09 | 192.168.11.19 | k8s worker、ceph osd | 1个1TB硬盘 |
| k8s-a-node010 | 192.168.11.20 | k8s worker、ceph osd | 1个1TB硬盘 |
准备工作
“准备工作在所有worker节点上做操作。
”
- 数据盘准备，除了sda是装了操作系统之外，sdb是用于osd盘的，不能被格式化文件系统
[root@k8s-a-node01 ~]# lsblk sda 8:0 0 500G 0 disk ├─sda1 8:1 0 2G 0 part /boot └─sda2 8:2 0 498G 0 part ├─centos-root 253:0 0 122G 0 lvm / ... sdb 8:16 0 1000G 0 disk # 就是这块
- 安装lvm2 如果在裸设备或未使用的分区上创建OSD，则Ceph OSD具有对LVM（逻辑卷管理）的依赖。
yum install -y lvm2
- 加载rbd模块 Ceph 需要使用带有 RBD 模块的 Linux 内核。许多 Linux 发行版都已经包含了 RBD 模块，但不是所有的发行版都有，所以要确认。
modprobe rbd lsmod | grep rbd
“Rook 的默认 RBD 配置仅指定了 layering 特性，以便与较旧的内核保持兼容。如果您的 Kubernetes 节点运行的是 5.4 或更高版本的内核，您可以选择启用其他特性标志。其中，fast-diff 和 object-map 特性尤其有用。
”
- 升级内核（可选） 如果你将使用 Ceph 共享文件系统（CephFS）来创建卷（Volumes），则 rook 官方建议使用至少 4.17 版本的 Linux 内核。如果你使用的内核版本低于 4.17，则请求的 Persistent Volume Claim（PVC）大小将不会被强制执行。存储配额（Storage quotas）只能在较新的内核上得到强制执行。
在 Kubernetes 中，PVC 用于向存储系统请求指定大小的存储空间。如果请求的 PVC 大小无法得到强制执行，则无法保证所请求的存储空间大小。由于存储配额在较旧的内核上无法得到强制执行，因此在使用 CephFS 创建卷时，如果使用较旧的内核版本，则可能无法正确地管理和分配存储空间。因此，rook 官方建议使用至少 4.17 版本的内核。
在所有k8s节点升级内核，之前忘记考虑这个事情，以后得提前升级好内核再搭建k8s集群，这种情况下升级内核，很难保证不会对k8s集群带来直接影响。注意了，生产环境可不能这么玩，得提前做好规划和准备。
我的centos7内核当前版本：
[root@k8s-a-node01 ~]# uname -r 3.10.0-1160.el7.x86_64
开始升级
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org rpm -Uvh https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm yum --enablerepo=elrepo-kernel install kernel-ml-devel kernel-ml-headers kernel-ml -y grub2-set-default 0 grub2-mkconfig -o /boot/grub2/grub.cfg reboot uname -sr # 升级完成后查看内核，已经满足条件 [root@k8s-a-node10 ~]# uname -sr Linux 6.2.9-1.el7.elrepo.x86_64 # 看看k8s是否正常，我的没问题，非常顺利。 kubectl get nodes kubectl get pod -n kube-system
部署ceph集群
- 部署Rook Operator
git clone --single-branch --branch v1.11.2 https://github.com/rook/rook.git cd rook/deploy/examples/ kubectl create -f crds.yaml -f common.yaml -f operator.yaml # 在继续操作之前，验证 rook-ceph-operator 是否正常运行 kubectl get deployment -n rook-ceph kubectl get pod -n rook-ceph
- 创建 Ceph 集群
“现在 Rook Operator已经运行起来了，接下来我们可以创建 Ceph 集群。
”
Rook允许通过自定义资源定义（CephCluster CRD）创建和自定义存储集群，创建群集的主要模式有四种不同的模式，关于模式以及关于cluster.yaml所有可用的字段和说明请仔细阅读和参考：https://rook.io/docs/rook/v1.11/CRDs/Cluster/ceph-cluster-crd/
本次创建的集群就先按官方示例里的cluster.yaml，不改动示例里的内容，它会在每个节点将创建一个OSD
kubectl create -f cluster.yaml
创建后查看，请确保所有Pod处于Running，OSD POD处于Completed：
[root@k8s-a-master ~]# kubectl get pod -n rook-ceph NAME READY STATUS RESTARTS AGE csi-cephfsplugin-4cx9v 2/2 Running 0 45m csi-cephfsplugin-84fd4 2/2 Running 0 45m csi-cephfsplugin-dnx6l 2/2 Running 0 45m csi-cephfsplugin-gb4f7 2/2 Running 0 45m csi-cephfsplugin-mtd67 2/2 Running 0 45m csi-cephfsplugin-nrnck 2/2 Running 0 45m csi-cephfsplugin-p5kmv 2/2 Running 0 45m csi-cephfsplugin-provisioner-9f7449fc9-9qf67 5/5 Running 0 45m csi-cephfsplugin-provisioner-9f7449fc9-k2cxc 5/5 Running 0 45m csi-cephfsplugin-vhfr7 2/2 Running 0 45m csi-cephfsplugin-wrgrb 2/2 Running 0 45m csi-cephfsplugin-xt6f6 2/2 Running 0 45m csi-rbdplugin-5mnb8 2/2 Running 0 45m csi-rbdplugin-9j69s 2/2 Running 0 45m csi-rbdplugin-ffg9b 2/2 Running 0 45m csi-rbdplugin-ggfxk 2/2 Running 0 45m csi-rbdplugin-h5gj7 2/2 Running 0 45m csi-rbdplugin-ks7db 2/2 Running 0 45m csi-rbdplugin-l2kmv 2/2 Running 0 45m csi-rbdplugin-l5jm2 2/2 Running 0 45m csi-rbdplugin-m7nc4 2/2 Running 0 45m csi-rbdplugin-provisioner-649c57b978-m5pdk 5/5 Running 0 45m csi-rbdplugin-provisioner-649c57b978-trp8j 5/5 Running 0 45m csi-rbdplugin-szchk 2/2 Running 0 45m rook-ceph-crashcollector-k8s-a-node01-6db7865746-clr4h 1/1 Running 0 50m rook-ceph-crashcollector-k8s-a-node02-97bb5864c-wqbx4 1/1 Running 0 37m rook-ceph-crashcollector-k8s-a-node03-59777d587b-gkr24 1/1 Running 0 41m rook-ceph-crashcollector-k8s-a-node04-7f77bbdcfc-qgh7x 1/1 Running 0 45m rook-ceph-crashcollector-k8s-a-node05-7cd59b4bc8-nkfgt 1/1 Running 0 45m rook-ceph-crashcollector-k8s-a-node06-74dc6dc879-n9z5z 1/1 Running 0 45m rook-ceph-crashcollector-k8s-a-node07-5f4c5c6c56-27zs9 1/1 Running 0 50m rook-ceph-crashcollector-k8s-a-node08-7fd7ff557-5qthx 1/1 Running 0 39m rook-ceph-crashcollector-k8s-a-node09-6b7d5645f4-fdpwp 1/1 Running 0 50m rook-ceph-crashcollector-k8s-a-node10-69f8f5cbfb-6mhtw 1/1 Running 0 33m rook-ceph-mgr-a-86f445fdcc-vdg4b 3/3 Running 0 50m rook-ceph-mgr-b-7b7967fd54-wjhxw 3/3 Running 0 50m rook-ceph-mon-a-6dd564d54d-cq4rb 2/2 Running 0 52m rook-ceph-mon-b-5c4875d7b9-xbd7l 2/2 Running 0 51m rook-ceph-mon-c-7fb466569d-qwb6v 2/2 Running 0 51m rook-ceph-operator-c489cccb5-8dtnz 1/1 Running 1 (116m ago) 14h rook-ceph-osd-0-f7cc57ddf-vc9tg 2/2 Running 0 50m rook-ceph-osd-1-7d79b4d4c-rbrkn 2/2 Running 0 50m rook-ceph-osd-2-564d78d445-jpjqk 2/2 Running 0 50m rook-ceph-osd-3-7ddf87bfd6-dlvmf 2/2 Running 0 45m rook-ceph-osd-4-849ddc4b68-5xg8h 2/2 Running 0 45m rook-ceph-osd-5-5ff57d4d55-skwv6 2/2 Running 0 45m rook-ceph-osd-6-668fcb969c-cwb46 2/2 Running 0 41m rook-ceph-osd-7-7876687b4d-r4b2g 2/2 Running 0 39m rook-ceph-osd-8-6c7784c4c-6xtv6 2/2 Running 0 37m rook-ceph-osd-9-654ffc5b66-qqhnr 2/2 Running 0 33m rook-ceph-osd-prepare-k8s-a-node01-6lf6r 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node02-8rcpw 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node03-dqcl4 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node04-8qtmq 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node05-qm78x 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node06-qq58n 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node07-lp9j8 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node08-vh4sn 0/1 Completed 0 33m rook-ceph-osd-prepare-k8s-a-node09-smvp8 0/1 Completed 0 32m rook-ceph-osd-prepare-k8s-a-node10-k6ggk 0/1 Completed 0 32m rook-ceph-tools-54bdbfc7b7-hqdw4 1/1 Running 0 24m [root@k8s-a-master ~]#
- 验证ceph集群
要验证群集是否处于正常状态，可以连接到 toolbox 工具箱并运行命令
kubectl create -f toolbox.yaml kubectl exec -it rook-ceph-tools-54bdbfc7b7-hqdw4 -n rook-ceph -- bash # 进去之后就可以执行各种命令了： ceph status ceph osd status ceph df rados df # 看看我的 [root@k8s-a-master examples]# kubectl exec -it rook-ceph-tools-54bdbfc7b7-pzkd4 -n rook-ceph -- bash bash-4.4$ ceph -s cluster: id: 0b64957b-9aaa-43ef-9946-211ca911dc92 health: HEALTH_OK services: mon: 3 daemons, quorum a,b,c (age 3m) mgr: a(active, since 64s), standbys: b osd: 10 osds: 10 up (since 116s), 10 in (since 2m) data: pools: 1 pools, 1 pgs objects: 2 objects, 449 KiB usage: 234 MiB used, 9.8 TiB / 9.8 TiB avail pgs: 1 active+clean bash-4.4$ ceph osd status ID HOST USED AVAIL WR OPS WR DATA RD OPS RD DATA STATE 0 k8s-a-node02 23.9M 999G 0 0 0 0 exists,up 1 k8s-a-node03 20.9M 999G 0 0 0 0 exists,up 2 k8s-a-node04 24.9M 999G 0 0 0 0 exists,up 3 k8s-a-node06 24.9M 999G 0 0 0 0 exists,up 4 k8s-a-node05 23.8M 999G 0 0 0 0 exists,up 5 k8s-a-node07 23.8M 999G 0 0 0 0 exists,up 6 k8s-a-node08 19.8M 999G 0 0 0 0 exists,up 7 k8s-a-node10 23.8M 999G 0 0 0 0 exists,up 8 k8s-a-node01 23.8M 999G 0 0 0 0 exists,up 9 k8s-a-node09 23.7M 999G 0 0 0 0 exists,up
每个 OSD 都有一个状态，可以是以下几种之一：
- up：表示该 OSD 正常运行，并且可以处理数据请求。
- down：表示该 OSD 当前无法运行或不可用，可能由于硬件故障或软件问题。
- out：表示该 OSD 不参与数据存储或恢复，这通常是由于管理员手动将其标记为不可用。
- exists：表示该 OSD 配置存在，但尚未启动或加入集群。
“在我这里，exists,up 表示该 OSD 配置存在，并且已经成功启动并参与了数据存储和恢复。exists 状态表示 OSD 配置已经存在，但是 OSD 还没有启动。只有当 OSD 运行后，状态才会变为 up。因此，exists,up 表示 OSD 的启动过程已经完成，并且 OSD 正常运行。
”
暴露Dashboard
Dashboard可以让我们查看Ceph集群的状态，包括整体的运行状况、mon仲裁状态、mgr、osd 和其他Ceph守护程序的状态、查看池和PG状态、显示守护程序的日志等。关于Dashboard的更多配置，请参考：https://rook.io/docs/rook/v1.11/Storage-Configuration/Monitoring/ceph-dashboard/
- 查看dashboard的svc，Rook将启用端口 8443 以进行 https 访问：
[root@k8s-a-master ~]# kubectl get svc -n rook-ceph NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rook-ceph-mgr ClusterIP 10.103.90.1 <none> 9283/TCP 52m rook-ceph-mgr-dashboard ClusterIP 10.108.66.238 <none> 8443/TCP 52m rook-ceph-mon-a ClusterIP 10.104.191.13 <none> 6789/TCP,3300/TCP 54m rook-ceph-mon-b ClusterIP 10.108.194.172 <none> 6789/TCP,3300/TCP 53m rook-ceph-mon-c ClusterIP 10.98.32.80 <none> 6789/TCP,3300/TCP 53m [root@k8s-a-master ~]#
- rook-ceph-mgr：是 Ceph 的管理进程（Manager），负责集群的监控、状态报告、数据分析、调度等功能，它默认监听 9283 端口，并提供了 Prometheus 格式的监控指标，可以被 Prometheus 拉取并用于集群监控。
- rook-ceph-mgr-dashboard：是 Rook 提供的一个 Web 界面，用于方便地查看 Ceph 集群的监控信息、状态、性能指标等。
- rook-ceph-mon：是 Ceph Monitor 进程的 Kubernetes 服务。Ceph Monitor 是 Ceph 集群的核心组件之一，负责维护 Ceph 集群的状态、拓扑结构、数据分布等信息，是 Ceph 集群的管理节点。
- 查看默认账号admin的密码
[root@k8s-a-master examples]# kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath="{['data']['password']}" | base64 --decode && echo $}<EVv58G-*C3@/?J1@t
“这个密码就是等会用来登录
”
- 使用 NodePort 类型的Service暴露dashboard dashboard-external-https.yaml
apiVersion: v1 kind: Service metadata: name: rook-ceph-mgr-dashboard-external-https namespace: rook-ceph labels: app: rook-ceph-mgr rook_cluster: rook-ceph spec: ports: - name: dashboard port: 8443 protocol: TCP targetPort: 8443 selector: app: rook-ceph-mgr rook_cluster: rook-ceph sessionAffinity: None type: NodePort
- 创建后NodePort类的svc后查看
[root@k8s-a-master examples]# kubectl get svc -n rook-ceph NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE rook-ceph-mgr ClusterIP 10.96.58.93 <none> 9283/TCP 28m rook-ceph-mgr-dashboard ClusterIP 10.103.131.77 <none> 8443/TCP 28m # 记得干掉 rook-ceph-mgr-dashboard-external-https NodePort 10.107.247.53 <none> 8443:32564/TCP 9m38s rook-ceph-mon-a ClusterIP 10.98.168.35 <none> 6789/TCP,3300/TCP 29m rook-ceph-mon-b ClusterIP 10.103.127.134 <none> 6789/TCP,3300/TCP 29m rook-ceph-mon-c ClusterIP 10.111.46.187 <none> 6789/TCP,3300/TCP 29m
“ClusterIP类型的SVC是集群部署后默认创建的，要干掉，不然影响NodePort类型的访问。
”
- 在任何节点访问dashboard
清理集群
“如果你不想要这个集群了，干掉这个集群也是很简单的，时间有限，我就不再输出，可参考官方文档：https://rook.io/docs/rook/v1.11/Getting-Started/ceph-teardown/#zapping-devices。后续我也会专门抽个时间做个分享。
”
写在最后
关于3种存储类型的实战，下次继续分享：
- 块：创建要由 Pod （RWO） 使用的块存储
- 共享文件系统：创建要在多个 Pod （RWX） 之间共享的文件系统
- 对象：创建可在 Kubernetes 集群内部或外部访问的对象存储
