1、glusterfs概述
1.1、glusterfs简介
glusterfs是一个可扩展,分布式文件系统,集成来自多台服务器上的磁盘存储资源到单一全局命名空间,以提供共享文件存储。
1.2、glusterfs特点
可以扩展到几PB容量 支持处理数千个客户端 兼容POSIX接口 使用通用硬件,普通服务器即可构建 能够使用支持扩展属性的文件系统,例如ext4,XFS 支持工业标准的协议,例如NFS,SMB 提供很多高级功能,例如副本,配额,跨地域复制,快照以及bitrot检测 支持根据不同工作负载进行调优1.3、glusterfs卷的模式
glusterfs中的volume的模式有很多中,包括以下几种:
分布卷(默认模式):即DHT, 也叫 分布卷: 将文件以hash算法随机分布到 一台服务器节点中存储。 复制模式:即AFR, 创建volume 时带 replica x 数量: 将文件复制到 replica x 个节点中。 条带模式:即Striped, 创建volume 时带 stripe x 数量: 将文件切割成数据块,分别存储到 stripe x 个节点中 ( 类似raid 0 )。 分布式条带模式:最少需要4台服务器才能创建。 创建volume 时 stripe 2 server = 4 个节点: 是DHT 与 Striped 的组合型。 分布式复制模式:最少需要4台服务器才能创建。 创建volume 时 replica 2 server = 4 个节点:是DHT 与 AFR 的组合型。 条带复制卷模式:最少需要4台服务器才能创建。 创建volume 时 stripe 2 replica 2 server = 4 个节点: 是 Striped 与 AFR 的组合型。 三种模式混合: 至少需要8台 服务器才能创建。 stripe 2 replica 2 , 每4个节点 组成一个 组。2、heketi概述
heketi是一个提供RESTful API管理gfs卷的框架,能够在kubernetes、openshift、openstack等云平台上实现动态的存储资源供应,支持gfs多集群管理,便于管理员对gfs进行操作,在kubernetes集群中,pod将存储的请求发送至heketi,然后heketi控制gfs集群创建对应的存储卷。
heketi动态在集群内选择bricks构建指定的volumes,以确保副本会分散到集群不同的故障域内。
heketi还支持任意数量的glusterfs集群,以保证接入的云服务器不局限于单个glusterfs集群。
3、部署heketi+glusterfs
环境:kubeadm安装的最新k8s 1.16.2版本,由1master+2node组成,网络插件选用的是flannel,默认kubeadm安装的k8s,会给master打上污点,本文为了实现gfs集群功能,先手动去掉了污点。
本文的glusterfs卷模式为复制卷模式。
另外,glusterfs在kubernetes集群中需要以特权运行,需要在kube-apiserver中添加–allow-privileged=true参数以开启此功能,默认此版本的kubeadm已开启。
3.1、准备工作
为了保证pod能够正常使用gfs作为后端存储,需要每台运行pod的节点上提前安装gfs的客户端工具,其他存储方式也类似。
3.1.1、所有节点安装glusterfs客户端需要安装gfs的kubernetes设置Label,因为gfs是通过kubernetes集群的DaemonSet方式安装的。
DaemonSet安装方式默认会在每个节点上都进行安装,除非安装前设置筛选要安装节点Label,带上此标签的节点才会安装。
安装脚本中设置DaemonSet中设置安装在贴有 storagenode=glusterfs的节点,所以这是事先将节点贴上对应Label。
查看是否加载
3.2、创建glusterfs集群
采用容器化方式部署gfs集群,同样也可以使用传统方式部署,在生产环境中,gfs集群最好是独立于集群之外进行部署,之后只需要创建对应的endpoints即可。这里采用Daemonset方式部署,同时保证已经打上标签的节点上都运行一个gfs服务,并且均有提供存储的磁盘。
3.2.1、下载相关安装文件在本集群中,下面用到的daemonset控制器及后面用到的deployment控制器的api版本均变为了apps/v1,所以需要手动修改下载的json文件再进行部署,资源编排文件中需要指定selector声明。避免出现以下报错:
修改api版本
为apps/v1
指定selector声明
对应后面内容的selector,用matchlabel相关联
注意:
这里使用的是默认的挂载方式,可使用其他磁盘作为gfs的工作目录 此处创建的namespace为default,可手动指定为其他namespace 3.2.3、查看gfs pods3.3、创建heketi服务
3.3.1、创建heketi的service account对象同样的,需要修改api版本以及增加selector声明部分。
3.4、创建gfs集群
3.4.1、复制二进制文件复制heketi-cli到/usr/local/bin目录下
修改topology-sample,manage为gfs管理服务的节点Node主机名,storage为节点的ip地址,device为节点上的裸设备,也就是用于提供存储的磁盘最好使用裸设备,不进行分区。
因此,需要预先在每个gfs的节点上准备好新的磁盘,这里分别在三个节点都新添加了一块/dev/sdb磁盘设备,大小均为10G。配置topology-sample
查看当前heketi的ClusterIP,并通过环境变量声明
执行如下命令创建gfs集群会提示Invalid JWT token: Token missing iss claim
这是因为新版本的heketi在创建gfs集群时需要带上参数,声明用户名及密码,相应值在heketi.json文件中配置,即:
执行了heketi-cli topology load之后,Heketi在服务器做的大致操作如下:
进入任意glusterfs Pod内,执行gluster peer status 发现都已把对端加入到了可信存储池(TSP)中。 在运行了gluster Pod的节点上,自动创建了一个VG,此VG正是由topology-sample.json 文件中的磁盘裸设备创建而来。 一块磁盘设备创建出一个VG,以后创建的PVC,即从此VG里划分的LV。 heketi-cli topology info 查看拓扑结构,显示出每个磁盘设备的ID,对应VG的ID,总空间、已用空间、空余空间等信息。
通过部分日志查看上面创建的heketi没有配置持久化的卷,如果heketi的pod重启,可能会丢失之前的配置信息,所以现在创建heketi持久化的卷来对heketi数据进行持久化,该持久化方式利用gfs提供的动态存储,也可以采用其他方式进行持久化。
在所有节点安装device-mapper*将配置信息保存为文件,并创建持久化相关信息
删除中间产物
创建持久化的heketi
查看持久化后heketi的svc,并重新声明环境变量
查看gfs集群信息,更多操作参照官方文档说明
4、创建storageclass
参数说明:
reclaimPolicy:Retain 回收策略,默认是Delete,删除pvc后pv及后端创建的volume、brick(lvm)不会被删除。 gidMin和gidMax,能够使用的最小和最大gid volumetype:卷类型及个数,这里使用的是复制卷,个数必须大于15、测试通过gfs提供动态存储
创建一个pod使用动态pv,在StorageClassName指定之前创建的StorageClass的name,即gluster-heketi:
创建pod并查看创建的pv和pvc
6、分析k8s通过heketi创建pv及pvc的过程
通过pvc及向storageclass申请创建对应的pv,具体可通过查看创建的heketi pod的日志
首先发现heketi接收到请求之后运行了一个job任务,创建了三个bricks,在三个gfs节点中创建对应的目录:创建lv,添加自动挂载
创建brick,设置权限
创建对应的volume
7、测试数据
测试使用该pv的pod之间能否共享数据,手动进入到pod并创建文件
查看创建的卷
将设备挂载查看卷中的数据,vol_08e8447256de2598952dcb240e615d0f为卷名称
8、测试deployment
测试通过deployment控制器部署能否正常使用storageclass,创建nginx的deployment
查看相应资源
查看挂载情况
在宿主机挂载和创建文件
扩容nginx副本,查看是否能正常挂载
至此,在k8s集群中部署heketi+glusterfs提供动态存储结束。
参考来源:
https://github.com/heketi/heketi
https://github.com/gluster/gluster-kubernetes
总结
到此这篇关于kubernetes存储之GlusterFS集群的文章就介绍到这了,更多相关kubernetes存储GlusterFS集群内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!
原文链接:https://www.cnblogs.com/ssgeek/p/11725648.html