一篇讲透Kubernetes与GlusterFS之间的爱恨情仇(一)

廖林荣
原创 5419       2017-10-31  

存储是容器编排中非常重要的一部分。Kubernetes从v1.2开始,提供了dynamic provisioning这一强大的特性,可以给集群提供按需分配的存储,并能支持包括AWS-EBS、GCE-PD、Cinder-Openstack、Ceph、GlusterFS等多种云存储。而GlusterFS作为分布式文件系统的后起之秀,他们之间会擦出什么样的火花呢?


首先,我们来谈谈Kubernetes部署的应用,可以分为无状态的和有状态的:

▪ 无状态的应用没有数据,Pod(一个或若干容器的集合)挂了被重新拉起,或者在Kubernetes集群不同的Node节点(可以认为是一台物理机或虚拟机)之间飘来飘去,都没有关系;

▪ 有状态的应用有数据需要保存,如果容器挂了被重新拉起,容器里面保存的数据就没了。


这时候我们自然而然地想到可以把数据映射到容器所在主机上,就像我们使用Docker时经常做的一样,可是这时候有个问题是,Kubernetes集群一般有多个Node节点,如果容器在挂了被重新拉起的时候被调度到其他的Node节点,那映射在原先主机上的数据还是在原先主机上,新的容器还是没有原来的数据。


怎么办呢?

这时候就需要本文的另一位重要的主角了--GlusterFS。把数据存储在分布式存储GlusterFS上,Pod通过网络连接到分布式存储,这样不管Pod怎么在不同的Node节点间飘,连接的都是同一个分布式存储,数据都还在。

事实上,Kubernetes的选择很多,目前Kubernetes支持的存储有下面这些:

GCEPersistentDisk
AWSElasticBlockStore
AzureFile
AzureDisk
FC (Fibre Channel)
FlexVolume
Flocker
NFS
iSCSI
RBD (Ceph Block Device)
CephFS
Cinder (OpenStack block storage)
Glusterfs
VsphereVolume
Quobyte Volumes
HostPath (就是刚才说的映射到主机的方式,多个Node节点会有问题)
VMware Photon
Portworx Volumes
ScaleIO Volumes
StorageOS


Kubernetes有这么多选择,GlusterFS只是其中之一,但为什么可以脱颖而出呢?GlusterFS,是一个开源的分布式文件系统,具有强大的横向扩展能力,通过扩展能够支持数PB存储容量和处理数千客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的存储资源聚集在一起,使用单一全局命名空间来管理数据。GlusterFS的Volume有多种模式,复制模式可以保证数据的高可靠性,条带模式可以提高数据的存取速度,分布模式可以提供横向扩容支持,几种模式可以组合使用实现优势互补。

下面就来看看Kubernetes和GlusterFS是怎么结合起来的吧,下面我们进入实战解决你对两者结合的所有困惑。


【部署Kubernetes】
部署方法见文章(点链接)从基础到完成部署,实战讲解Kubernetes如何落地
假设Kubernetes部署在
Master:

Node:

Kubernetes版本:


【部署GlusterFS】
部署机器(这里跟Kubernetes部署在同样的机器):


在每台机器的/etc/hosts加上


(以下安装过程--到安装结束的地方--可以使用 http://192.168.58.228:9007/glusterfs/install/ 上的一键安装包安装)
安装yum源(每台机器执行)

安装glusterfs(每台机器执行):

(安装结束)
启动glusterfs(每台机器执行):

组建集群(192.168.XX.A 机器执行):

验证(192.168.XX.A 机器执行):

看到其他两个点的信息即代表GlusterFS集群组建成功


【Kubernetes使用GlusterFS】
有两种方式,手动和自动,手动需要每次使用存储时自己创建GlusterFS的卷(GlusterFS的数据存储在卷Volume上);自动利用Kubernetes的 Dynamic Provisioning 特性,可以由Kubernetes自动创建GlusterFS卷,但是需要先部署Heketi软件,并且安装GlusterFS的机器上还要有裸磁盘。


手动方式
1)创建GlusterFS卷
▪ 新建卷(3个副本的复制模式)

▪ 启动卷

▪ 查看卷:

可以看到所创建的卷的信息。

2)Kubernetes创建PV等存储
Kubernetes用PV(PersistentVolume)、PVC(PersistentVolumeClaim)来使用GlusterFS的存储,PV与GlusterFS的Volume相连,相当于提供存储设备,所以需要由知道GlusterFS Volume的系统管理员创建(这里我们自己就是系统管理员);PVC消耗PV提供的存储,由应用部署人员创建,应用直接使用PVC进而使用PV的存储。
以下操作在Kubernetes Master节点执行
系统管理员创建 endpoint、service、pv(endpoint和service不用每次都建,可以复用):
先创建三个文件:
▪ glusterfs-endpoints.json:

▪ glusterfs-service.json:

▪ glusterfs-pv.yaml:

执行命令创建:

查看endpoint、service、pv:


3)Kubernetes创建应用

应用部署人员创建pvc及应用(这里以mysql为例):
创建两个文件:
▪ glusterfs-pvc.yaml:

▪ mysql-deployment.yaml:

执行命令创建:

查看pvc、service:

查看pod:

可以看到 Pod 已经被调度到 192.168.XX.A 上。

mysql客户端连接并查看数据库:

可以看到我们建的liao数据库还在,说明虽然 pod 重新调度,但数据还在。

有人会疑问这里两次连接的都是 192.168.XX.A 的 31016 端口,为什么说连接到了不同的Pod,这是因为Kubernetes的kube-proxy会把我们配置的Service里映射的端口在每个Kubernetes Node上都开出来,也就是在任何一个Kubernetes Node上都能连接到Pod,Pod重新调度后,还是在任何一个Kubernetes Node上都能连接,但后面的Pod其实已经是新的了。


本文主要介绍了Kubernetes与GlusterFS的部署方式和如何使用手动的方式使用存储时自己创建GlusterFS的卷(GlusterFS的数据存储在卷Volume上)。下文我们将继续介绍如何自动利用Kubernetes的 Dynamic Provisioning 特性。敬请继续关注!

恒生技术之眼原创文章,未经授权禁止转载。详情见转载须知

联系我们

恒 生 技 术 之 眼