Kubernetes持久化存储2——探究实验

　　本文在“创建PV，创建PVC挂载PV，创建POD挂载PVC”这个环境的基础上，进行各种删除实验，并记录、分析各资源的状态。

　　实验创建了一个PV、一个PVC挂载了PV、一个POD挂载PVC，并编写了两个简单的小脚本来快速创建和删除环境。对应的脚本如下所示：

　　需要注意的是在创建PV时，PV并不会去检查你配置的server是否真的存在；也不会检查server上是否有一个可用的NFS服务；当然更不会检查你设置的storage大小是否真有那么大。个人感觉PV的设置只是一个声明，系统并不会对此做任何检查。PVC的挂载也只是根据配额的大小和访问模式，过滤一下PV，并以最小的代价支持。

　　创建PV，创建PVC挂载PV，创建POD挂载PVC。在删除PV后，PVC状态从Bound变为Lost，Pod中的Volume仍然能用，数据也没有被删除。

　　设置PV时，如果设置了回收策略是“回收”的时候，在删除PVC时，系统（Controller-Manager）会启动一个recycler的Pod，用于清理数据卷中的内容。每种数据卷的回收Pod是不同的，都有自己特定的逻辑。本文以NFS为例，给出具体配置及Pod描述如下：

　　如果不进行上面的设置的话，默认回收Pod用的image是gcr上的busybox，因为种种原因，在国内是无法下载的（即使你的机器上有gcr的busybox也不可以，还需要设置镜像下载策略为IfNotPresent，否则会一直去gcr查询是否有新版本的镜像，这也会导致imagePullError）。所以必须要在Controller-Manager中进行设置，设置成随便哪个busybox。

创建PV，创建PVC挂载PV，创建POD挂载PVC。删除PVC后，PV状态从Bound变为Available，系统（controller-manager）调用持久化存储清理插件（recycler-for-pv0001），将PVC对应的PV清空。Pod中的Volume仍然能用，但volume中的数据被删除了。

　　创建PV，创建PVC挂载PV，创建POD挂载PVC。删除Pod后，PV、PVC状态没变，Pod中的Volume对应的NFS数据没有被删除。