引言
传统的运维中,往往需要管理员手动先在存储集群分配空间,然后才能挂载到应用中去。 Kubernetes 的最新版中, dynamic provisioning 升级到了 beta ,并支持多种存储服务的动态预配置,从而可以更有效地利用存储环境中的存储容量,达到按需使用存储空间的目的。本文将介绍 dynamic provisioning 这一特性,并以 GlusterFS 为例,说明存储服务与 k8s 的对接。
dynamic provisioning :
存储是容器编排中非常重要的一部分。 Kubernetes 从 v1.2 开始,提供了 dynamic provisioning 这一强大的特性,可以给集群提供按需分配的存储,并能支持包括 AWS-EBS 、 GCE-PD 、 Cinder-Openstack 、 Ceph 、 GlusterFS 等多种云存储。非官方支持的存储也可以通过编写 plugin 方式支持。 在没有 dynamic provisioning 时,容器为了使用 Volume ,需要预先在存储端分配好,这个过程往往是管理员手动的。在引入 dynamic provisioning 之后, Kubernetes 会根据容器所需的 volume 大小,通过调用存储服务的接口,动态地创建满足所需的存储。
Storageclass :
管理员可以配置 storageclass ,来描述所提供存储的类型。以 AWS-EBS 为例,管理员可以分别定义两种 storageclass : slow 和 fast 。 slow 对接 sc1(机械硬盘), fast 对接 gp2 (固态硬盘)。应用可以根据业务的性能需求,分别选择两种 storageclass 。
Glusterfs :
一个开源的分布式文件系统,具有强大的横向扩展能力,通过扩展能够支持数 PB 存储容量和处理数千客户端。 GlusterFS 借助 TCP/IP 或 InfiniBandRDMA 网络将物理分布的存储资源聚集在一起,使用单一全局命名空间来管理数据。
Heketi:
Heketi ( https://github.com/heketi/heketi ),是一个基于 RESTful API 的 GlusterFS 卷管理框架。 Heketi 可以方便地和云平台整合,提供 RESTful API 供 Kubernetes 调用,实现多 glusterfs 集群的卷管理。另外, heketi 还有保证 bricks 和它对应的副本均匀分布在集群中的不同可用区的优点。
部署基于 GlusterFS 的 dynamic provisioning 1 、安装 GlusterFS 。可以参见官方文档,在此不赘述。 2 、部署 heketi 。本文将以容器化的形式部署 heketi 。 heketi 的 yaml 如下: apiVersion: extensions/v1beta1 kind: Deployment metadata: name: heketi labels: app: heketi spec: replicas: 1 template: metadata: labels: app: heketi spec: containers: - name: heketi image:caicloud: heketi ports: - containerPort: 8080 volumeMounts: - mountPath: /etc/heketi name: heketi-volume - mountPath: /root/.ssh name: ssh-volume volumes: - name: ssh-volume hostPath: path: /root/.ssh # This node must be able to ssh to other nodes. - name: heketi-volume hostPath: path: /root/heketi nodeName: {{heketi_node}} # Pinned to node
等 heketi 开始成功运行后,需要将 glusterfs 集群的配置载入,可以通过 curl api 的形式,也可以通过 heketi 的客户端来载入,如 ./heketi-cli load --json=new-cluster.json 。 new-cluster.json 中定义了 glusterfs 集群的各个节点 IP 、可用分区等信息。典型的配置例子: https://github.com/heketi/heketi/blob/master/client/cli/go/topology-sample.json
注意事项: Heketi 需要使用能够免密 ssh 到 glusterfs 集群所有节点的私钥,并且 heketi 会在 glusterfs 集群将指定的分区格式化, 并调用 pvcreate 和 lvcreate 将分区组装成 volume group 。
3 、部署 StorageClass
apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: glusterfs-rep3 provisioner: kubernetes.io/glusterfs parameters: resturl: "http://192.168.1.111:8081" //heketi 地址,也可以填域名 clusterid: "630372ccdc720a92c681fb928f27b53f" // 可选,要使用的集群 id restuser: "admin" // 可选, authentication 的用户名 secretNamespace: "default" // 可选, authentication 的密码所在的 secret 所在的 namespace secretName: "heketi-secret" // 可选, authentication 的密码所在的 secret gidMin: "40000" // 能够使用的最小 gid ,可选,每个 gluster volume 都有唯一的 gid gidMax: "50000" // 能够使用的最大 gid ,可选 volumetype: "replicate:3" // 可选, glusterfs 的 volume 类型,数字为副本的数量
这里 volumetype 填了 replicate:3 ,同理,我们也可以定义其他卷类型的 storageclass ,比如 disperse:4:2 ,表示使用纠错卷( disperse ),每 4 份 brick 做 2 份冗余。 volumetype: none 将会默认使用分布式卷。
4 、创建 PVC ( Persistent Volume Claim ),指定 storageclass ,并声明所需存储大小。 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gluster-pvc-10G annotations: volume.beta.kubernetes.io/storage-class: glusterfs-rep3 // 指定 storageclass spec: accessModes:
创建 pvc 后, Kubernetes 会调用 heketi 的 create volume API 。之后 heketi 将会去检查 glusterfs 集群的可用空间。本文指定了 rep3 的 storageclass, 所以需要 3 个节点有至少 10G 的可用磁盘空间。如果满足条件, Kubernetes 则会创建相应大小的 PV ( Persistent Volume ),并绑定该 PVC 。否则,该 PVC 将一直停留在 pending 状态。 本文指定了 3 个副本的 gluster 存储,其实只要将 annotations 中的 storageclass 换个名字,应用就可以使用其他类型的存储,非常方便。
5 、验证 PVC 成功绑定 PV 后,可以让应用使用该 PVC 作为存储。我们可以新建一个 debian 的 pod ,用来验证, yaml 如下: apiVersion: v1 kind: Pod metadata: name: gluster-tester spec: containers:
通过 kubectl exec 进入该容器的终端后,就可以在 /mnt/glusterfs 目录下使用 10G 的 glusterfs 存储。因为 gluster-pvc-10G 是 ReadWriteMany (可以被多个 pod 挂载读写)的,所以可以在其他应用中也使用这个 PVC ,达到数据共享的目的。
总结
可以看到,有使用存储需求的应用,都只需要声明大小,指定 storageclass , Kubernetes 就可以动态地配置相应大小的存储,应用完全的不需要底层存储的细节。 最后, glusterfs/heketi 相关的 yaml 和部署说明可以在 https://github.com/heketi/heketi/tree/master/extras/kubernetes 找到。
1
612 2017-03-03 17:00:26 +08:00 via iPhone
刚刚的微软 p-seller 大聚会上才听了你们的宣讲,真巧。
|