之前，我们是在分配好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<vessels/noah>下可以看到经过测试加持的yaml文件，坑踩完了，总结下，大概就是版本不一样，日志不好找带来的问题。
