Rook系列-01-osd启动流程
概述
阅读本文可能需要有手动部署 Ceph 集群的经验。
OSD启动的流程
Rook 本身很复杂，包含很多 Controller，而 Rook 的复杂不仅体现在这里，并且 Ceph 也非常复杂，在部署和运维上有很多需要注意的地方。本文主要剖析 Rook 启动 osd 的流程，如果有部署过 Ceph 的经验，应该知道加入 osd 大概有两个步骤，一是先 prepare，也就是检查节点上的一些设备是否符合安装 osd，二是激活，也就是 activate。这个过程在 Rook 里也同样需要。
下面是部署完毕后的 Operator 和 osd 相关的 pod 的情况，测试条件下，部署了 3 个 osd，每个节点有 11 块盘。
|
|
Rook 代码结构是比较清晰的，关于 osd 的代码可以从 pkg/operator/ceph/cluster/osd 找到。
现在都用 ceph-volume 来安装 Ceph 集群了，ceph-deploy 已经不维护了。不用 ceph-volume 就用 ceph 本来的命令。
由于有一个 osd prepare 的过程，在 Rook 里是通过 init-container 来运行一个脚本来实现的。
关于手动部署，一定要看看 Ceph 的官方文档 。
只有当状态为 completed 的时候才会真正的去启动 osd。
osd 的部署就是通过 lsblk、udevadm 这些命令来做检查的，下面的命令即使 Rook 里用到的命令，在节点上执行一次看看结果，Rook 会根据一些条件来筛选合适的设备来启动 osd。
|
|
|
|
|
|
通过下面的命令，我们在 osd 的节点上运行一下，ceph-volume 是用 python 写的，基本上就是通过一些磁盘、设备等命令来检查节点上的设备。如果 osd prepare 之后没有启动真正的 osd pod 的话，就需要查一下 osd prepare pod 的日志了，或者看一下 local-device 开头的 ConfigMap，里面会有执行 ceph-volume 的结果，下图的结果明显就是设备因为某些原因被拒绝了，具体尅看 rejected_resons 的结果。
|
|
上面的代码走读比较麻烦，跳转来跳转去，下面是我画的一个图，可以参考这个图来理解 Rook 是如何启动 osd 的。