Kubernetes与GlusterFS的爱恨情仇


文章来源:恒生技术之眼

Kubernetes,容器管理领域的领导者;GlusterFS,分布式文件系统的后起之秀,他们之间会擦出什么样的火花呢?

用Kubernetes部署的应用可以分为无状态的和有状态的,无状态的应用没有数据,Pod(一个或若干容器的集合)挂了被重新拉起,或者在Kubernetes集群不同的Node节点(可以认为是一台物理机或虚拟机)之间飘来飘去,都没有关系;有状态的应用有数据需要保存,如果容器挂了被重新拉起,容器里面保存的数据就没了。这时候我们自然而然的想到可以把数据映射到容器所在主机上,就像我们使用Docker时经常做的一样,可是这时候有个问题是,Kubernetes集群一般有多个Node节点,如果容器在挂了被重新拉起的时候被调度到其他的Node节点,那映射在原先主机上的数据还是在原先主机上,新的容器还是没有原来的数据。

怎么办呢?

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

这么说是Kubernetes需要GlusterFS了,都说“被需要的都有恃无恐”,那么GlusterFS是不是可以有恃无恐了呢?--当然不是,毕竟在这个残酷的世界,没有人是可以活得那么舒服的。事实上,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:
192.168.XX.A

Node:
192.168.XX.A
192.168.XX.B
192.168.XX.C

Kubernetes版本:
# kubectl --version
Kubernetes v1.5.2

部署GlusterFS

部署机器(这里跟Kubernetes部署在同样的机器):
192.168.XX.A
192.168.XX.B
192.168.XX.C

在每台机器的/etc/hosts加上:
192.168.XX.A glusterfs1
192.168.XX.B glusterfs2
192.168.XX.C glusterfs3

安装yum源(每台机器执行):
yum install centos-release-gluster

安装GlusterFS(每台机器执行):
yum -y install glusterfs glusterfs-fuse glusterfs-server

安装结束。

启动GlusterFS(每台机器执行):
systemctl start glusterd.service  
systemctl enable glusterd.service  

组建集群(192.168.XX.A 机器执行):
gluster peer probe glusterfs2  
gluster peer probe glusterfs3  

验证(192.168.XX.A 机器执行):
# gluster peer status 
Number of Peers: 2

Hostname: glusterfs2
Uuid: 30efc726-35b5-4502-8f7f-f238ea44f3aa
State: Peer in Cluster (Connected)
Other names:
192.168.XX.B

Hostname: glusterfs3
Uuid: 2c7aaa1b-4d51-4560-88be-cbe42e30b7a3
State: Peer in Cluster (Connected)
Other names:
192.168.XX.C

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

Kubernetes使用GlusterFS

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

手动方式:

1)创建GlusterFS卷

新建卷(3个副本的复制模式):
(在每台机器执行:)
mkdir -p /data/brick1/gv0

(在一台机器执行:)
gluster volume create gv0 replica 3 glusterfs1:/data/brick1/gv0 glusterfs2:/data/brick1/gv0 glusterfs3:/data/brick1/gv0 force

启动卷:
(在一台机器执行:)
gluster volume start gv0 

查看卷:
(在一台机器执行:)
# gluster volume info  

Volume Name: gv0
Type: Replicate
Volume ID: 2f8147de-fcb6-4219-81a3-71d6cfcaa609
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: glusterfs1:/data/brick1/gv0
Brick2: glusterfs2:/data/brick1/gv0
Brick3: glusterfs3:/data/brick1/gv0
Options Reconfigured:
transport.address-family: inet
nfs.disable: on

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

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:
{
"kind": "Endpoints",
"apiVersion": "v1",
"metadata": {
"name": "glusterfs-cluster"
},
"subsets": [
{
  "addresses": [
    {
      "ip": "192.168.XX.A"
    }
  ],
  "ports": [
    {
      "port": 1
    }
  ]
},
{
  "addresses": [
    {
      "ip": "192.168.XX.B"
    }
  ],
  "ports": [
    {
      "port": 1
    }
  ]
},
{
  "addresses": [
    {
      "ip": "192.168.XX.C"
    }
  ],
  "ports": [
    {
      "port": 1
    }
  ]
}
]


glusterfs-service.json:
{
"kind": "Service",
"apiVersion": "v1",
"metadata": {
"name": "glusterfs-cluster"
},
"spec": {
"ports": [
  {"port": 1}
]
}


glusterfs-pv.yaml:
apiVersion: v1
kind: PersistentVolume
metadata:
name: gluster-dev-volume1
labels:
name: mysql1 
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
glusterfs:
endpoints: "glusterfs-cluster"
path: "gv0"
readOnly: false

执行命令创建:
kubectl apply -f glusterfs-endpoints.json
kubectl apply -f glusterfs-service.json
kubectl apply -f glusterfs-pv.yaml

查看Endpoint、Service、PV:
kubectl get ep
kubectl get svc
kubectl get pv

3)Kubernetes创建应用

应用部署人员创建PVC及应用(这里以MySQL为例):

创建两个文件:

glusterfs-pvc.yaml:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: glusterfs-mysql1
spec:
accessModes:
- ReadWriteMany
resources:
requests:
  storage: 1Gi
selector:
matchLabels:
  name: "mysql1"

mysql-deployment.yaml:
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
name: mysql
spec:
type: NodePort
ports:
- name: mysqlport
port: 3306
nodePort: 31016
selector:
name: mysql
---
apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
name: mysql
spec: 
replicas: 1
template: 
metadata: 
  labels: 
    name: mysql
spec: 
  containers: 
    - name: mysqlcontainer
      image: registry.hundsun.com/library/mysql:5.7.12
      imagePullPolicy: IfNotPresent
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: root12345
      ports: 
        - containerPort: 3306
      volumeMounts:
        - name: gluster-mysql-data
          mountPath: "/var/lib/mysql"
  volumes:
  - name: gluster-mysql-data
    persistentVolumeClaim:
      claimName: glusterfs-mysql1

执行命令创建:
kubectl apply -f glusterfs-pvc.yaml
kubectl apply -f mysql-deployment.yaml

查看PVC、Service:
kubectl get pvc
kubectl get svc

查看Pod:
# kubectl get po -o wide
NAME                       READY     STATUS    RESTARTS   AGE       IP            NODE
mysql-1858843218-68cts     1/1       Running   0          30m       10.254.39.9   192.168.XX.C

看到MySQL Pod是Running状态,表示容器创建成功,运行在 192.168.XX.C 节点上。

4)测试

可以用MySQL客户端连接(连接的IP是任意Kubernetes Node节点IP,31016和root12345是mysql-deployment.yaml里指定的映射端口和MySQL root用户密码),连接后我们建一个数据库liao:
# ./mysql -h 192.168.XX.A -P 31016 -uroot -proot12345
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 3
Server version: 5.7.12 MySQL Community Server (GPL)

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> 
MySQL [(none)]> create database liao;
Query OK, 1 row affected (0.02 sec)

MySQL [(none)]> 
MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| liao               |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.01 sec)

MySQL [(none)]> 

可以看到已经成功创建了一个数据库liao。

现在我们测试一下Pod重新调度后数据还在不在:

删除Pod :
kubectl delete po mysql-1858843218-68cts

Pod被删除后Kubernetes会自动把它重新拉起,在哪个Node节点上拉起由Kubernetes自己调度决定。

过一小会儿重新查看Pod:
# kubectl get po -o wide
NAME                       READY     STATUS    RESTARTS   AGE       IP            NODE
mysql-1858843218-v1fvf     1/1       Running   0          28s       10.254.34.5   192.168.XX.A

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

MySQL客户端连接并查看数据库:
# ./mysql -h 192.168.XX.A -P 31016 -uroot -proot12345
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.7.12 MySQL Community Server (GPL)

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> 
MySQL [(none)]> 
MySQL [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| liao               |
| mysql              |
| performance_schema |
| sys                |
+--------------------+
5 rows in set (0.03 sec)

MySQL [(none)]> 

可以看到我们建的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。

1)部署Heketi

部署在:
192.168.XX.A

安装:
yum install heketi heketi-client -y

修改/etc/heketi/heketi.json(省略了没有修改的部分):
{
...
"port": "8083",

...

"_glusterfs_comment": "GlusterFS Configuration",
"glusterfs": {
"_executor_comment": [
  "Execute plugin. Possible choices: mock, ssh",
  "mock: This setting is used for testing and development.",
  "      It will not send commands to any node.",
  "ssh:  This setting will notify Heketi to ssh to the nodes.",
  "      It will need the values in sshexec to be configured.",
  "kubernetes: Communicate with GlusterFS containers over",
  "            Kubernetes exec api."
],
"executor": "ssh",

"_sshexec_comment": "SSH username and private key file information",
"sshexec": {
  "keyfile": "/home/liao/key/key",
  "user": "root",
  "port": "22",
  "fstab": "/etc/fstab"
},

...
}


这里主要把端口改为8083了(防止冲突),executor改为ssh, sshexec的各项配置也做了相应修改。

其中的Keyfile制作方法:
ssh-keygen -t rsa

输入key(随便起的名字),一直回车。

制作完成后会在当前目录下生成key、key.pub,把 key.pub上传到GlusterFS三台服务器的/root/.ssh/下面,并重命名为authorized_keys,/etc/heketi/heketi.json中的Keyfile指向生成的key(包含路径)。

启动:
systemctl enable heketi
systemctl start heketi

看日志:
journalctl -u heketi

(Heketi数据目录: /var/lib/heketi)

验证:
curl http://192.168.XX.A:8083/hello

或:
heketi-cli --server http://192.168.XX.A:8083 cluster list

配置节点:

新建topology.json:
{
"clusters": [
    {
        "nodes": [
            {
                "node": {
                    "hostnames": {
                        "manage": [
                            "glusterfs1"
                        ],
                        "storage": [
                            "192.168.XX.A"
                        ]
                    },
                    "zone": 1
                },
                "devices": [
                    "/dev/xvde"
                ]
            },
            {
                "node": {
                    "hostnames": {
                        "manage": [
                            "glusterfs2"
                        ],
                        "storage": [
                            "192.168.XX.B"
                        ]
                    },
                    "zone": 2
                },
                "devices": [
                    "/dev/xvde"
                ]
            },
            {
                "node": {
                    "hostnames": {
                        "manage": [
                            "glusterfs3"
                        ],
                        "storage": [
                            "192.168.XX.C"
                        ]
                    },
                    "zone": 1
                },
                "devices": [
                    "/dev/xvde"
                ]
            }
        ]
    }
]


载入配置:
export HEKETI_CLI_SERVER=http://192.168.XX.A:8083
heketi-cli topology load --json=topology.json

查看拓扑:
heketi-cli topology info

建个大小为2G的volume试试:
heketi-cli volume create --size=2

查看:
heketi-cli volume list

删除:
heketi-cli volume delete <Id>

2)Kubernetes创建StorageClass

Kubernetes通过创建StorageClass来使用 Dynamic Provisioning 特性,StorageClass连接Heketi,可以根据需要自动创建GluserFS的Volume,StorageClass还是要系统管理员创建,不过StorageClass不需要每次创建,因为这个不需要很多,不同的PVC可以用同一个StorageClass。

新建文件:

glusterfs-storageclass.yaml:
apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
name: slow
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://192.168.XX.A:8083"
volumetype: "replicate:3"

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

执行命令创建:
kubectl apply -f glusterfs-storageclass.yaml

查看:
# kubectl get storageclass
NAME      TYPE
slow      kubernetes.io/glusterfs

3)Kubernetes创建应用

应用部署人员创建PVC及应用(还是以MySQL为例)。

创建两个文件:

glusterfs-pvc.yaml:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: glusterfs-mysql1
annotations:
volume.beta.kubernetes.io/storage-class: "slow"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
  storage: 1Gi

mysql-deployment.yaml:
apiVersion: v1
kind: Service
metadata:
name: mysql
labels:
name: mysql
spec:
type: NodePort
ports:
- name: mysqlport
port: 3306
nodePort: 31016
selector:
name: mysql
---
apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
name: mysql
spec: 
replicas: 1
template: 
metadata: 
  labels: 
    name: mysql
spec: 
  containers: 
    - name: mysqlcontainer
      image: registry.hundsun.com/library/mysql:5.7.12
      imagePullPolicy: IfNotPresent
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: root12345
      ports: 
        - containerPort: 3306
      volumeMounts:
        - name: gluster-mysql-data
          mountPath: "/var/lib/mysql"
  volumes:
  - name: gluster-mysql-data
    persistentVolumeClaim:
      claimName: glusterfs-mysql1

执行命令创建:
kubectl apply -f glusterfs-pvc.yaml
kubectl apply -f mysql-deployment.yaml

查看Endpoint、Service、PV,可以发现这些都自动建好了:
# kubectl get ep
NAME                                 ENDPOINTS                                                     AGE
glusterfs-dynamic-glusterfs-mysql1   192.168.XX.A:1,192.168.XX.B:1,192.168.XX.C:1                  9s

# kubectl get svc
NAME                                 CLUSTER-IP       EXTERNAL-IP     PORT(S)     AGE
glusterfs-dynamic-glusterfs-mysql1   10.254.132.6     <none>          1/TCP       42s

# kubectl get pv
NAME                                       CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                      REASON    AGE
pvc-f81121a0-ae8b-11e7-a91a-286ed488c82a   1Gi        RWX           Delete          Bound     default/glusterfs-mysql1             4m

查看PVC:
# kubectl get pvc
NAME               STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
glusterfs-mysql1   Bound     pvc-f81121a0-ae8b-11e7-a91a-286ed488c82a   1Gi        RWX           5m

可以看到PV和PVC已经绑定好。

还是可以用刚才的命令连接到MySQL:
mysql -h 192.168.XX.A -P 31016 -uroot -proot12345

按刚才的方式测试MySQL Pod重新调度后数据还在不在,可以发现数据还在。

从上面可以看到手动方式需要系统管理员每次手动建GlusterFS的Volume和Kubernetes的PV,或者系统管理员事先建好一批Volume和PV;而自动方式不需要,Kubernetes可以根据应用部署人员的需要动态创建Volume和PV,节省了很多工作量,推荐使用自动方式。

原文链接:


作者:廖林荣,本文转载自恒生技术之眼,如需转载请至恒生技术之眼官网申请授权。

0 个评论

要回复文章请先登录注册