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”挂载在容器内指定的路径。】