负责把PVC绑定到PV的是一个持久化存储卷控制循环，这个控制器也是kube-manager-controller的一部分运行在master上。而真正把目录挂载到容器上的操作是在POD所在主机上发生的，所以通过kubelet来完成。而且创建PV以及PVC的绑定是在POD被调度到某一节点之后进行的，完成这些操作，POD就可以运行了。下面梳理一下挂载一个PV的过程：
用户提交一个包含PVC的POD
调度器把根据各种调度算法把该POD分配到某个节点，比如node01
Node01上的kubelet等待Volume Manager准备存储设备
PV控制器调用存储插件创建PV并与PVC进行绑定
Attach/Detach Controller或Volume Manager通过存储插件实现设备的attach。（这一步是针对块设备存储）
Volume Manager等待存储设备变为可用后，挂载该设备到/var/lib/kubelet/pods/<Pod 的 ID>/volumes/kubernetes.io~<Volume 类型 >/<Volume 名字 >目录上
Kubelet被告知卷已经准备好，开始启动POD，通过映射方式挂载到容器中
StorageClassPV是运维人员来创建的，开发操作PVC，可是大规模集群中可能会有很多PV，如果这些PV都需要运维手动来处理这也是一件很繁琐的事情，所以就有了动态供给概念，也就是Dynamic Provisioning。而我们上面的创建的PV都是静态供给方式，也就是Static Provisioning。而动态供给的关键就是StorageClass，它的作用就是创建PV模板。
创建StorageClass里面需要定义PV属性比如存储类型、大小等；另外创建这种PV需要用到存储插件。最终效果是，用户提交PVC，里面指定存储类型，如果符合我们定义的StorageClass，则会为其自动创建PV并进行绑定。
我们这里演示一下NFS的动态PV创建
kubernetes本身支持的动态PV创建不包括nfs，所以需要使用额外插件实现。nfs-client
我这里就按照网站的例子来创建，里面的内容毫无修改，当然你需要自己准备NFS服务器。由于用于提供动态创建PV的程序是运行在POD中，所以你需要保证你的Kubernetes节点到NFS的网络通畅，我这里就在我的Kubernetes集群的某个节点上建立的NFS服务。下面是PVC文件
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mytomcat-pvc spec: storageClassName: managed-nfs-storage accessModes: - ReadWriteMany resources: requests: storage: 500Mi当你应用这个PVC的时候，由于例子中的storageClassName也是managed-nfs-storage（当然这个名字你可以修改）就会去自动创建PV。
下图是在Node02这个节点上看到的
基于这种形式，我们只需要根据我们有的存储系统来定义StorageClass，通过名称来标识不同种类的存储，比如SSD、block-device这种名称，而不需要定义具体大小。那么使用人员就可以根据需要通过StorageClass的名字来使用，从而实现动态创建PV的过程。
这里有个要求就是你的存储系统需要提供某种接口来让controller可以调用并传递进去PVC的参数去创建PV，很多云存储都支持。可是也有不支持的，比如NFS就不支持所以我们需要一个单独的插件来完成这个工作。也就是例子中使用的quay.io/external_storage/nfs-client-provisioner镜像，但是创建PV也需要相关权限，也就是例子中rabc.yaml部分。在定义StorageClass中有一个叫做provisioner: fuseim.pri/ifs这个就是插件的名称，这个名称其实也就是官方例子中deployment中设置的名字，这个名字你可以修改。
当然我们说过有些本身就支持，比如下面的kubernetes官网中的一个AWS的例子：
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: slow provisioner: kubernetes.io/aws-ebs parameters: type: io1 iopsPerGB: "10" fsType: ext4kubernetes.io/aws-ebs就是kubernetes内置的存储插件名称，如果你使用aws就用这个名称就好。因为kubernetes就会去调用AWS的API来创建存储然后在创建PV。
这里你可能会有个疑问，为什么开篇的例子里面也用了storageClassName: normal，可是我们并没有定义任何StorageClass。其实虽然我们使用了，但是系统上并没有一个叫做normal的存储类，这时候还是静态绑定，只是绑定的时候它会考虑你的PV和PVC中的存储类名称是否一致。当然如果是静态绑定你可以不写storageClassName，因为如果开起一个的叫做DefaultStorageClassplugin插件就会默认有这样一个存储类，它会自动添加到你的任何没有明确声明storageClassName的PV和PVC中。
本地持久化存储