v1.5.1 kubernetes中RBD作为StorageClass/PVC/Volume

之前，我们是在分配好Pool后自己写程序创建image，然后分配给Pod等，后来发现Persistent Volume Provision这个feature觉得很方便，准备试下。

一、大概是我遇到最费解的坑

kubectl create -f rbd.yaml 
Error from server (BadRequest): error when creating "rbd.yaml": StorageClass in version "v1beta1" cannot be handled as a StorageClass: [pos 129]: json: expect char '"' but got char '['

一直以为是两个错

• 版本
  不要纠结这个错，因为报错是迷惑你的。。版本这个1.5.1用apiVersion: storage.k8s.io/v1beta1
• yaml里字段写错
  关于第二个错，StorageClass和PV的写法不一致，就按照我之前用PV的经验写的，如下

monitors: 
- cephmon1:6789
- cephmon2:6789
- cephmon3:6789

后来我不经意看到有一行

Ceph monitors, comma delimited.

改成下面这样，StorageClass就创建成功了

monitors: cephmon1:6789,cephmon2:6789,cephmon3:6789

可以用kubectl get storageclass

kubectl get storageclasses
NAME             TYPE
fast             kubernetes.io/rbd   
faster           kubernetes.io/rbd   
fastest          kubernetes.io/rbd   
slow (default)   kubernetes.io/rbd 

二、在PVC创建过程中，1.4/1.5/1.6中你需要配置的annotation key都是不一样的

• 1.5
  Try a PVC with volume.beta.kubernetes.io/storage-class instead (note beta instead of alpha).
• 1.6
  详见features/issues/36，应该是1.6变成.io/v1

正常vs不正常的PVC可以看下对比

# kubectl get pvc
NAME               STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
mysql-pv-claim     Bound     pvc-4ba718d9-0351-11e7-9b93-fa163e0ed0f9   20Gi       RWO           26m
noah-mysql-claim   Pending                                                                       3h

三、rbd runtime

有一点不太友好，你不看日志就不知道错误出在哪里的，经验值大概知道kubelet或scheduler要能调用rbd，这个pending就是因为rbd没装。其实这个坑遇到的人很多，搜索一下就能看到。我google的关键词是 hyperkube install rbd

E0307 16:25:11.096994       1 rbd_util.go:341] rbd: Error creating rbd image: executable file not found in $PATH
E0307 16:25:11.097006       1 rbd.go:310] rbd: create volume failed, err: executable file not found in $PATH
W0307 16:25:26.095622       1 rbd_util.go:336] failed to create rbd image, output 
W0307 16:25:26.095669       1 rbd_util.go:336] failed to create rbd image, output 
W0307 16:25:26.095700       1 rbd_util.go:336] failed to create rbd image, output

** 其实coreos挺良心，可以看看他们的wrap **

关于用了hyperkube和kubeadm的同学，如果你用的是这个image gcr.io/google_containers/hyperkube-amd64:v1.2.1 可以这样来补救你的环境(总比呼啦推倒重来好) ** 可能你还需要，手动安装下curl **

RUN curl https://raw.githubusercontent.com/ceph/ceph/master/keys/release.asc | apt-key add - && \
    echo deb http://download.ceph.com/debian-hammer/ jessie main | tee /etc/apt/sources.list.d/ceph.list && \
    apt-get update && \
    DEBIAN_FRONTEND=noninteractive apt-get install -q -y ceph-common && \
    apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

四、StorageClass必须加鉴权

这是个我觉得不太友好的坑，

• 背景：
  我的测试ceph集群没开鉴权
• 表现：
  storageclass创建成功了，但是在persistent volume claim的时候，
  PVC状态是Pending，就很费解，然后看日志，Controller-Manager和Scheduler的日志里有个错，找不到adminID，那我就加个假的secrets，PVC的状态对了。
  但是Pod的状态一直是ContainerCreating= =然后我去找kube-node的日志，kubelet上面报错，找不到StorageClass userId的Secret

参考：
https://github.com/xcompass/hyperkube
https://github.com/kubernetes/kubernetes/issues/23924
http://blog.kubernetes.io/2016/10/dynamic-provisioning-and-storage-in-kubernetes.html

• 结论：StorageClass中的相关配置，这几行都不能少，即userId/adminId

adminId: admin
adminSecretName: ceph-secret-admin
adminSecretNamespace: "default"
userId: kube
userSecretName: ceph-secret-user

总结

在我的git repository下可以看到经过测试加持的yaml文件，坑踩完了，总结下，大概就是版本不一样，日志不好找带来的问题。