• 背景
• ceph集群
• node上准备ceph
• RBD用作volume
• RBD用作PV/PVC
• RBD用作storage class
• 总结

背景

为什么k8s需要RBD呢？以前用到的volume，有 configmap 、empty dir、hostpath，configmap通常是用来向容器注入配置的，而empty dir、hostpath 也能够用来存储数据，但他们都有一个致命的问题：如果容器被删除了，数据也就跟着丢失了。这对一些无状态应用来说没什么，因为他们的数据可能早就进数据库了，但对一些有状态的应用来说（比如说mysql），就是个问题了。

Ceph RBD、Cephfs，都是解决这个问题的办法。

Ceph RBD是个什么东西呢？

我们知道，存储可以分为三类：对象存储（例如aws s3、aliyun oss）、文件存储（例如nfs、nas）、块存储。而Ceph RBD(RADOS Block Devices)即为块存储的一种，下文的Cephfs则是文件存储的一种。

下面简要走一下ceph RBD的使用。

ceph集群

因为公司有专门团队做Ceph，我只管用就行，跳过Ceph集群的安装过程。对于k8s来说，需要的Ceph信息有这些：

IP地址、端口号 管理员用户名 管理员keyring

node上准备ceph

接下来会用一些ceph的命令行，用来根ceph集群交互。

yum/apt install ceph-common ceph-fs-common -y

ceph命令行需要2个配置文件，具体配置问ceph团队就行了。

• /etc/ceph/ceph.conf
• /etc/ceph/ceph.client.admin.keyring

RBD是这样用的：用户在Ceph上创建Pool（逻辑隔离），然后在Pool中创建image（实际存储介质），之后再将image挂载到本地服务器的某个目录上。

记住下面几条命令就行了。

# rbd list    #列出默认pool下的image
# rbd list -p k8s   #列出pool k8s下的image
# rbd create foo -s 1024  #在默认pool中创建名为foo的image，大小为1024MB
# rbd map foo #将ceph集群的image映射到本地的块设备
/dev/rbd0
# ls -l /dev/rbd0   #是b类型
brw-rw---- 1 root disk 252, 0 May 22 20:57 /dev/rbd0
$ rbd showmapped    #查看已经map的rbd image
id pool image snap device    
0  rbd  foo   -    /dev/rbd0
# mount /dev/rbd1 /mnt/bar/   #此时去mount会失败，因为image还没有格式化文件系统
mount: /dev/rbd1 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/rbd1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
# mkfs.ext4 /dev/rbd0   #格式化为ext4
...
Writing superblocks and filesystem accounting information: done
# mount /dev/rbd0 /mnt/foo/   #重新挂载
# df -h |grep foo             #ok
/dev/rbd0       976M  2.6M  907M   1% /mnt/foo

如果你有自己挂载过硬盘的经验，对RBD的操作应该是很快就能熟悉了。

上面都是在默认pool中做的，我们在k8s里，当然要用自己的pool了。

# ceph osd lspools # 看看已经有那些pool
# ceph osd pool create k8s 128 #创建pg_num 为128的名为k8s的pool
# rados df

有了自己专属的 pool以后，把上面创建image的过程重新走一下吧。

# rbd create foobar -s 1024 -p k8s #在k8s pool中创建名为foobar的image，大小为1024MB

不要挂载！不要挂载！不要挂载！

RBD用作volume

前面已经创建好了image foobar，给volume用简单直接粗暴，挂就行了。

apiVersion: v1
kind: Pod
metadata:
  name: rbd
spec:
  containers:
    - image: gcr.io/nginx
      name: rbd-rw
      volumeMounts:
      - name: rbdpd
        mountPath: /mnt/rbd
  volumes:
    - name: rbdpd
      rbd:
        monitors:
        - '1.2.3.4:6789'
        pool: k8s
        image: foobar
        fsType: ext4
        readOnly: false
        user: admin
        keyring: /etc/ceph/ceph.client.admin.keyring 

Pod启动后，可以看到文件系统由k8s做好并挂载到了容器里。我们将/etc/hosts文件拷贝到/mnt/rbd/目录去。

# kubectl exec rbd -- df -h|grep rbd
/dev/rbd6       976M  2.6M  907M   1% /mnt/rbd
# kubectl exec rbd -- cp /etc/hosts /mnt/rbd/
# kubectl exec rbd -- cat /mnt/rbd/hosts
# Kubernetes-managed hosts file.
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.3.249    rbd

然后将Pod删除、重新挂载foobar image。

前面Pod要求各node上都要有keyring文件，很不方便也不安全。新的Pod我使用推荐的做法：secret（虽然也安全不到哪里）

先创建一个secret。

apiVersion: v1
kind: Secret
metadata:
  name: ceph-secret
type: "kubernetes.io/rbd"  
data:
  key: QVFCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9PQ==

在新的Pod里Ref这个secret。

apiVersion: v1
kind: Pod
metadata:
  name: rbd3
spec:
  containers:
    - image: gcr.io/nginx
      name: rbd-rw
      volumeMounts:
      - name: rbdpd
        mountPath: /mnt/rbd
  volumes:
    - name: rbdpd
      rbd:
        monitors: 
        - '1.2.3.4:6789'
        pool: k8s
        image: foobar
        fsType: ext4
        readOnly: false
        user: admin
        secretRef:
          name: ceph-secret

再来看看前面写到image上的文件还在不在。

kubectl exec rbd3 -- cat /mnt/rbd/hosts
# Kubernetes-managed hosts file.
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.244.3.249    rbd

你会发现，哎，文件还在哎！对，这就是RBD的效果。但注意，Volume已经不存在了，虽然数据保住了，但这其实不是我们希望的持久化存储的方式。

RBD用作PV/PVC

volume是一种比较初级的使用方式，中级的方式是使用PV/PVC。

简单说说PV/PVC。集群管理员会创建多个PV（Persist Volume，持久化卷，不区分namespace），而普通用户会创建PVC（PV Claim，PV声明），k8s会从满足PVC的要求中选择一个PV来与该PVC绑定，之后再将PV对应的image挂载到容器中。

来看个例子。

先在k8s pool里创建一个名为pv的 image。

rbd image create pv -s 1024 -p k8s

再创建一个PV，使用上面创建的image pv。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ceph-rbd-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  rbd:
    monitors:
      - '1.2.3.4:6789'
    pool: k8s
    image: pv
    user: admin
    secretRef:
      name: ceph-secret
    fsType: ext4
    readOnly: false
  persistentVolumeReclaimPolicy: Recycle

看下现在pv的状态，还是 Available。

kubectl get pv|grep rbd
ceph-rbd-pv                                1Gi        RWO            Recycle          Available

创建一个PVC，要求一块1G的存储。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ceph-rbd-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

因为上面已经创建满足要求的PV了，可以看到pvc和pv的状态都已经是Bound了。

# kubectl get pvc|grep rbd
ceph-rbd-pv-claim   Bound     pvc-bdaf8358-5dc6-11e8-a37d-ecf4bbdeea94   1Gi        RWO            fast           10s
# kubectl get pv|grep ceph-rbd-pv
ceph-rbd-pv     1Gi    RWO    Recycle    Bound     12m

RBD用作storage class

为什么前面说PV/PVC是一个“中级”解决方案呢？

很简单啊，管理员不可能没事就等着给人创建RBD image、PV，而一次创建大量PV等着人用又显得很不云计算。

storage class的出现，就是为了解决这个问题。

简单来说，storage创建需要的材料，只需要访问ceph RBD的IP/Port、用户名、keyring、pool，不需要提前创建image；当用户创建一个PVC时，k8s查找是否有符合PVC请求的storage class类型，如果有，则依次：

1. 到ceph集群上创建image
2. 创建一个PV，名字为pvc-xx-xxx-xxx，大小pvc请求的storage。
3. 将上面的PV与PVC绑定，格式化后挂到容器中

是不是很简单？管理员只要创建好storage class就行了，后面的事情用户自己就可以搞定了。当然了，为了防止流氓用户，设置一下Resource Quota还是很有必要的。

下面走一个。

先创建一个SC。跟PV一样，SC也是集群范围的（RBD认为是fast的）。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 172.25.60.3:6789
  adminId: admin
  adminSecretName: ceph-secret
  adminSecretNamespace: resource-quota
  pool: k8s
  userId: admin
  userSecretName: ceph-secret
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"

之后创建应用的时候，需要同时创建 pvc+pod，二者通过claimName关联。pvc中需要指定其storageClassName为上面创建的sc的name（即fast）。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: rbd-pvc-pod-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: fast

RBD只支持 ReadWriteOnce 和 ReadOnlyAll，不支持ReadWriteAll。注意这两者的区别点是，不同nodes之间是否可以同时挂载。同一个node上，即使是ReadWriteOnce，也可以同时挂载到2个容器上的。

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: rbd-pvc-pod
  name: ceph-rbd-sc-pod2
spec:
  containers:
  - name: ceph-rbd-sc-nginx
    image: gcr.io/nginx
    volumeMounts:
    - name: ceph-rbd-vol1
      mountPath: /mnt/ceph-rbd-pvc/nginx
      readOnly: false
  volumes:
  - name: ceph-rbd-vol1
    persistentVolumeClaim:
      claimName: rbd-pvc-pod-pvc

其实我觉得PVC的创建都可以直接省掉，可以新增一个类型，直接Pod请求就得了，类似下面StatefulSets里的volumeClaimTemplates。

如果是多副本的应用怎么办呢？可以用StatefulSet。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: gcr.io/nginx
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "fast"
      resources:
        requests:
          storage: 8Gi

此时去看PVC，可以看到创建了3个PVC。

# kubectl get pvc|grep www
www-nginx-0         Bound     pvc-05f10f64-58df-11e8-8bd4-ecf4bbdeea94   8Gi        RWO            fast           6d
www-nginx-1         Bound     pvc-0e1768f3-58df-11e8-8bd4-ecf4bbdeea94   8Gi        RWO            fast           6d
www-nginx-2         Bound     pvc-17347e8e-58df-11e8-8bd4-ecf4bbdeea94   8Gi        RWO            fast           6d
# kubectl get pv|grep www
pvc-05f10f64-58df-11e8-8bd4-ecf4bbdeea94   8Gi        RWO            Delete           Bound       dex/www-nginx-0                     fast                     6d
pvc-0e1768f3-58df-11e8-8bd4-ecf4bbdeea94   8Gi        RWO            Delete           Bound       dex/www-nginx-1                     fast                     6d
pvc-17347e8e-58df-11e8-8bd4-ecf4bbdeea94   8Gi        RWO            Delete           Bound       dex/www-nginx-2                     fast                     6d

但注意不要用Deployment。因为，如果Deployment的副本数是1，那么还是可以用的，跟Pod一致；但如果副本数 >1 ，此时创建deployment后会发现，只启动了1个Pod，其他Pod都在ContainerCreating状态。过一段时间describe pod可以看到，等volume等很久都没等到。

 Unable to mount volumes for pod "nginx-deployment-55bd845d95-vjs58_dex(73be7605-5dcf-11e8-a37d-ecf4bbdeea94)": timeout expired waiting for volumes to attach or mount for pod "default"/"nginx-deployment-55bd845d95-vjs58". list of unmounted volumes=[nginx-rbd-v1]. list of unattached volumes=[nginx-rbd-v1 default-token-62cfx]

总结

本文介绍了kubernetes使用RBD的必要性，一些简单的RBD命令行及RBD手工操作方式，以及RBD在Volume、PV、StorageClass三种方式下的使用。

Ref

• 使用Ceph RBD为Kubernetes集群提供存储卷
• 初试 Kubernetes 集群使用 Ceph RBD 块存储