Persistent Volume Claim（PVC）和 Persistent Volume（PV）
持久卷声明和持久卷
Pod绑定PVC，PVC绑定PV，达到Pod绑定使用PV的目的；
PV是全局的，属于Cluster，没有命名空间；
Deployment不认识PVC模板；只有StatefulSet才会编号PVC；
环境上可能有成千上万个PVC，这就意味着运维人员需要去创建PV。手工是不可能的；
所以有了Storage Class，作为创建PV的模板;
Pod——PVC——Storage Class——PV
PVC 可以理解为持久化存储的“接口”，它提供了对某种持久化存储的描述，但不提供具体的实现；而这个持久化存储的实现部分则由 PV 负责完成。
容器持久化存储，总结一下整体流程。
【用户提交请求创建pod，Kubernetes发现这个pod声明使用了PVC，那就靠PersistentVolumeController帮它找一个PV配对。
没有现成的PV，就去找对应的StorageClass，帮它新创建一个PV，然后和PVC完成绑定。
新创建的PV，还只是一个API 对象，需要经过“两阶段处理”变成宿主机上的“持久化 Volume”才真正有用：
第一阶段由运行在master上的AttachDetachController负责，为这个PV完成 Attach 操作，为宿主机挂载远程磁盘；
第二阶段是运行在每个节点上kubelet组件的内部，把第一步attach的远程磁盘 mount 到宿主机目录。这个控制循环叫VolumeManagerReconciler，运行在独立的Goroutine，不会阻塞kubelet主循环。
完成这两步，PV对应的“持久化 Volume”就准备好了，POD可以正常启动，将“持久化 Volume”挂载在容器内指定的路径。】
PV的存储模式有：
1、ReadWriteOnce——可以被单个节点以读/写方式挂载；
2、ReadOnlyMany——可以被多个节点以只读方式挂载；
3、ReadWriteMany——可以被多个节点以读/写方式挂载；
卷的几种状态：
1、Bound（已绑定）——卷已经被声明绑定
2、Available（可用）——一块空闲资源还没有被任何声明绑定
3、Released（已释放）——声明被删除，但是资源还未被集群重新声明
4、Failed（失败）——该卷的自动回收失败
本地持久化存储：Local Persistent Volume
用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器 Volume。
1、Local Persistent Volume 并不适用于所有应用
2、其次，相比于正常的 PV，一旦这些节点宕机且不能恢复时，Local Persistent Volume 的数据就可能丢失。这就要求使用 Local Persistent Volume 的应用必须具备数据备份和恢复的能力
第一个难点：如何把本地磁盘抽象成 PV？
1、你绝不应该把一个宿主机上的目录当作 PV 使用
2、一个 Local Persistent Volume 对应的存储介质，一定是一块额外挂载在宿主机的磁盘或者块设备
第二个难点：调度器如何保证 Pod 始终能被正确地调度到它所请求的 Local Persistent Volume 所在的节点上呢？
1、在调度的时候考虑 Volume 分布：
对于 Local PV 来说，节点上可供使用的磁盘（或者块设备），必须是运维人员提前准备好的
StorageClass的一个字段：
volumeBindingMode=WaitForFirstConsumer——延迟绑定，推迟到调度的时候（即Pod已经进入调度器）
当你提交了 PV 和 PVC 的 YAML 文件之后，Kubernetes 就会根据它们俩的属性，以及它们指定的 StorageClass 来进行绑定。只有绑定成功后，Pod 才能通过声明这个 PVC 来使用对应的 PV。
如果你使用的是 Local Persistent Volume 的话，就会发现，这个流程根本行不通。