Rook是一款运行在Kubernetes集群中的存储服务编排工具,在0.8版本中,Rook已经变成Beta发行版,如果还没有尝试过Rook,可以现在尝鲜。
Rook是什么,为什么很重要?Ceph运行在Kubernetes集群中很久了,为什么要有这么大的变动?如果以前玩过Ceph集群,肯定深知维护Ceph集群的复杂性,Rook就是为此而生,使用Kubernetes分布式平台简化大量针对Ceph存储的操作和维护工作。
Rook通过一个操作器(operator)完成后续操作,只需要定义需要的状态就可以了。Rook通过操作器监控状态需求变化,并将配置文件分配到集群上生效。操作器关注包括各种集群运行和启停所需的状态信息。本文将详细讨论这些细节。
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专题[1]。
完全自动化
最简单使用方式就是“使用所有资源”模式。意味着操作者自动在所有节点上启动OSD设备,Rook会用如下标准监控并发现可用设备:
设备没有分区
设备没有格式化的文件系统
自声明模式
第二种模式给用户更大的选择控制权限,用户可以指定哪些节点或者设备会被使用。有几个层级方式进行配置:
节点:
声明哪些节点上会启动OSD
采用“标签”方式用Kubernetes来声明节点
声明启动OSD的设备名
声明设备过滤规则,并在其上启动OSD
采用SSD或者NVME设备创建bluestore的metadata分区,bluestore数据分区分布在各种设备上
Kubernetes中,需要存储的客户端都会使用PV并挂载到Pod上,Rook提供FlexVolume插件,此插件可以使访问Ceph集群更加简便,只需要声明存储类相关的池,然后在Pod上声明指向存储类的PVC,本例[2]将解释在Pod中挂载RBD镜像的具体步骤。
除了基础的RADOS集群,Rook还会帮助管理对象空间。如果声明需要一个对象存储空间,Rook将:
为对象空间创建metadata和数据池
启动RGW Daemon,如果需要还可以运行高可用实例
通过RGW Daemon创建Kubernetes设备提供负载均衡。对象存储则在存储内部提供
最后,但不仅限如此,rook还可以配置CephFS提供共享存储空间服务。当生命在集群中需要文件系统时,Rook会:
为CephFS创建metadata和数据池
创建文件系统
使用MDS启动期望数量的实例
下一步工作
Rook运行前提是有一套存储需要配置的Kubernetes集群。Rook的目标就是让配置存储的工作越来越简单,当然目前我们还只是处在这一工作的开始。
我们正在积极开发Rook[4]项目,期待有更多功能出现。我们也希望更多专家出现在社区,如果有问题,可以通过Rook Slack[5]和我们沟通。
相关链接:
https://rook.io/docs/rook/v0.8/ceph-cluster-crd.html#storage-selection-settings
https://rook.io/docs/rook/v0.8/block.html
https://rook.io/docs/rook/v0.8/filesystem.html#consume-the-shared-file-system-k8s-registry-sample
https://github.com/rook/rook
https://rook-slackin.herokuapp.com/
原文链接:https://ceph.com/community/rook-automating-ceph-kubernetes/
3天Kubernetes线下实战培训