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

http://rdc.hundsun.com/portal/article/826.html

http://rdcqii.hundsun.com/portal/article/827.html

存储是容器编排中非常重要的一部分。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部署在
Master：

Node：

Kubernetes版本：

部署机器（这里跟Kubernetes部署在同样的机器）：

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

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

安装glusterfs（每台机器执行）:

（安装结束）
启动glusterfs（每台机器执行）：

组建集群（192.168.XX.A 机器执行）：

验证（192.168.XX.A 机器执行）：

看到其他两个点的信息即代表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其实已经是新的了。

▲自动方式

自动方式需要先部署Heketi软件，Heketi用来管理GlusterFS，并提供RESTful API接口供Kubernetes调用。Heketi需要使用裸磁盘，假设三个GlusterFS节点上都挂了一块裸磁盘 /dev/xvde。接下来我们进入实战模式

部署在

安装：（以下安装过程--到安装结束的地方--可以使用 http://192.168.58.228:9007/glusterfs/heketi/ 上的一键安装包安装）
改为公司yum源

安装

（安装结束）
修改/etc/heketi/heketi.json（省略了没有修改的部分）:

这里主要把端口改为8083了（防止冲突），executor 改为 ssh， sshexec 的各项配置也做了相应修改。
其中的keyfile制作方法：

输入key（随便起的名字）一直回车。制作完成后会在当前目录下生成key、key.pub，把 key.pub 上传到GlusterFS三台服务器的 /root/.ssh/ 下面，并重命名为 authorized_keys，/etc/heketi/heketi.json 中 的 keyfile 指向 生成的 key（包含路径）。
启动：

看日志：

（Heketi数据目录： /var/lib/heketi）
验证：

或：

▲配置节点
新建 topology.json：

载入配置：

查看拓扑：

建个大小为2G的volume试试：

查看：

删除：

Kubernetes通过创建StorageClass来使用 Dynamic Provisioning 特性，StorageClass连接Heketi，可以根据需要自动创建GluserFS的Volume，StorageClass还是要系统管理员创建，不过StorageClass不需要每次创建，因为这个不需要很多，不同的PVC可以用同一个StorageClass。
新建文件：glusterfs-storageclass.yaml:

replicate:3代表会创建三个副本复制模式的GluserFS Volume。
执行命令创建：

查看：

【Kubernetes创建应用】

应用部署人员创建pvc及应用（本文还是以mysql为例）
创建两个文件：
▪ glusterfs-pvc.yaml：

▪ mysql-deployment.yaml:

执行命令创建：

查看endpoint、service、pv，可以发现这些都自动建好了：

查看PVC：

c可以看到PV和PVC已经绑定好。
还是可以用刚才的命令连接到mysql：

按刚才的方式测试mysql pod重新调度后数据还在不在，可以发现数据还在。

从上一篇文章可以看到手动方式需要系统管理员每次手动建GlusterFS的Volume和Kubernetes的PV，或者系统管理员事先建好一批Volume和PV。而本文所介绍的自动方式则是不需要，Kubernetes可以根据应用部署人员的需要动态创建Volume和PV，节省了很多工作量，所以，得出的结论就是推荐使用自动方式。

本文转载自恒生技术之眼