Rook是什么，为什么很重要？Ceph运行在Kubernetes集群中很久了，为什么要有这么大的变动？如果以前玩过Ceph集群，肯定深知维护Ceph集群的复杂性，Rook就是为此而生，使用Kubernetes分布式平台简化大量针对Ceph存储的操作和维护工作。
Rook通过一个操作器（operator）完成后续操作，只需要定义需要的状态就可以了。Rook通过操作器监控状态需求变化，并将配置文件分配到集群上生效。操作器关注包括各种集群运行和启停所需的状态信息。本文将详细讨论这些细节。
Mons
Ceph集群中最重要的信息是Mons的quorum，一般集群中有有三个Mons，保持高可用以及quorum可用性以防数据不可用，当创建集群是，Rook将会：- 启动特定节点上的Mons，确保他们在quorum中
- 定期确定Mons状态，确保他们在quorum中
- 如果某个Mon出现故障，并且没有重新启动，操作器会往quorum中添加一个新的mon，并将失效的移除quorum
- 更新Ceph客户端和Daemons的IP地址
Mgr
Mgr是一个无状态服务，提供集群信息。除了启动核心功能外，Rook还参与配置其它两个Mgr插件：- 搜集Prometheus状态
- 启动Ceph面板，并启动服务点
OSDs
集群中最具挑战的是OSD部分，存储部分的核心部件。大规模集群会在上线前大量使用OSD。Rook会根据如何使用，以两种模式配置他们，可以参考更多OSD专题。完全自动化
最简单使用方式就是“使用所有资源”模式。意味着操作者自动在所有节点上启动OSD设备，Rook会用如下标准监控并发现可用设备：- 设备没有分区
- 设备没有格式化的文件系统
Rook不会使用不满足以上标准的设备。操作完毕后（一般要几分钟），就拥有一套OSD配置完毕的存储集群。
自声明模式
第二种模式给用户更大的选择控制权限，用户可以指定哪些节点或者设备会被使用。有几个层级方式进行配置：- 节点：
- 声明哪些节点上会启动OSD
- 采用“标签”方式用Kubernetes来声明节点
- 设备：
- 声明启动OSD的设备名
- 声明设备过滤规则，并在其上启动OSD
- 采用SSD或者NVME设备创建bluestore的metadata分区，bluestore数据分区分布在各种设备上
这种模式很灵活，可以选择需要启动OSD的设备。
客户访问
Kubernetes中，需要存储的客户端都会使用PV并挂载到Pod上，Rook提供FlexVolume插件，此插件可以使访问Ceph集群更加简便，只需要声明存储类相关的池，然后在Pod上声明指向存储类的PVC，本例将解释在Pod中挂载RBD镜像的具体步骤。RGW
除了基础的RADOS集群，Rook还会帮助管理对象空间。如果声明需要一个对象存储空间，Rook将：- 为对象空间创建metadata和数据池
- 启动RGW Daemon，如果需要还可以运行高可用实例
- 通过RGW Daemon创建Kubernetes设备提供负载均衡。对象存储则在存储内部提供
MDS
最后，但不仅限如此，rook还可以配置CephFS提供共享存储空间服务。当生命在集群中需要文件系统时，Rook会：- 为CephFS创建metadata和数据池
- 创建文件系统
- 使用MDS启动期望数量的实例
Ceph工具
即使实现了自动化，仍然需要使用Ceph工具维护正常运转。但是随着越来越自动化，工具的依赖度会慢慢降低。同时，如果需要运行Ceph工具，要么启动一个工具箱，或者通过连接到Mon Daemon容器执行这些工具。下一步工作
Rook运行前提是有一套存储需要配置的Kubernetes集群。Rook的目标就是让配置存储的工作越来越简单，当然目前我们还只是处在这一工作的开始。我们正在积极开发Rook项目，期待有更多功能出现。我们也希望更多专家出现在社区，如果有问题，可以通过Rook Slack和我们沟通。
本文转自DockOne-Rook：基于Ceph的Kubernetes存储解决方案