StorageClass

• PV的动态供给原理

• PV的动态删除

• PV与PVC的绑定

PV的动态供给原理

在前面的文章中，我们介绍了通过StorageClass可以实现PV的动态供给。接下来，我们来介绍一下动态供给的基本原理。

在动态供给时，当创建好一个PVC后，会自动完成以下三个步骤：

1、自动地在Ceph中创建一个RBD块 2、自动地在k8s集群中创建一个PV，将PV与RBD关联起来 3、自动地将PVC与PV进行绑定

那么问题来了，上面的三个步骤，是“谁”执行的呢？

回忆一下《RBD实践》一文中动态供给的流程，首先我们需要创建如下的一个名字为rbd的StorageClass，然后我们再创建一个storageClassName为rbd的PVC，就会自动地为PVC创建一个PV

在上面的yaml文件中，有两个字段很关键：metadata.name: rbd与provisioner: ceph.com/rbd，它们的意思是，如果监听到一个storageClassName为rbd的PVC，则为由ceph.com/rbd为其自动地创建一个PV（即执行上面的三个操作）

ceph.com/rbd是个什么东西呢？我们再回忆一下《RBD实践》一文，在创建上述StorageClass的同时，我们还在k8s集群中创建了一个名字叫rbd-provisioner的Deployment对象，实例数设置为了1。

此时，动态供给的原理基本上已经清晰：rbd-provisioner这个Pod已经提前设置好了ceph.com/rbd这个参数，当我们创建一个provisioner为ceph.com/rbd的StorageClass后，rbd-provisioner这个Pod就会根据yaml文件找到这个StorageClass的名字，然后会通过apiserver监听storageClassName为rbd的PVC，当监听到新的PVC被创建时，便会执行上面的前两个步骤：创建RBD块及创建PV；然后由kube-controller-manager完成PVC与PV的绑定工作。

上面的rbd-provisioner这个Pod会识别provisioner为ceph.com/rbd的StorageClass。其实在kube-controller-manager中，有一个controller它能够识别provisioner为kubernetes.io/rbd的StorageClass。也就是说，如果我们创建一个provisioner: kubernetes.io/rbd的StorageClass，那么我们就不需要创建上面的rbd-provisioner就可以使用ceph。不过要注意的是kube-controller-manager在创建rbd块时，依赖于本机的rbd命令，所以只有使用二进制安装的k8s集群才能使用provisioner: kubernetes.io/rbd的StorageClass。

PV的动态删除

PV的动态删除我们要考虑以下两种情况：

1、删除PVC时，自动删除其绑定的PV、及自动删除PV关联的RBD块 2、只删除PV时，自动删除其关联的RBD块（该效果无法实现）

与动态供给一样，自动删除时也是由Controller（rbd-provisioner）完成的。所以，要达到动态删除的效果，PV与PVC必须要属于某个StorageClass，且有一个Controller在监听这种StorageClass。

不是所有的StorageClass的PV都支持动态删除，在kube-controller-manager内置的StorageClass中，rbd、gce等块存储都支持动态删除，而nfs等文件系统存储则不支持动态删除。

要支持动态删除，PV的persistentVolumeReclaimPolicy要设置为Delete。ceph.com/rbd与kubernetes.io/rbd两种StorageClass的Controller已经把其动态创建的PV的该字段的值设置为了Delete，所以由它们自动创建的PV在删除时，会自动地删除关联的RBD块。当然，我们也可以手动先在Ceph中创建一个RBD块，然后创建一个PV关联该RBD块，然后再手动创建一个PVC绑定该PV，记得把PV与PVC的StorageClass设置为rbd，那么在删除该PVC时，也能自动地删除PV及RBD块。

上面的第二种情况：只删除PV时，自动删除其关联的RBD块是无法实现的，即使PV指明了StorageClass且有对应的Controller。

PV与PVC的绑定

to be continued