所属技术领域：
K8s
|名词定义|
PersistentVolumeClaim（简称PVC）是用户存储的请求，PVC消耗PV的资源，可以请求特定的大小和访问模式，需要指定归属于某个Namespace，在同一个Namespace的Pod才可以指定对应的PVC。
当需要不同性质的PV来满足存储需求时，可以使用StorageClass来实现。
每个 PVC 中都包含一个 spec 规格字段和一个 status 声明状态字段。
|技术特点|
有了PV,为什么又设计了PVC？
1.职责分离，PVC中只用声明自己需要的存储size、access mode（单node独占还是多node共享？只读还是读写访问？）等业务真正关心的存储需求（不用关心存储实现细节），PV和其对应的后端存储信息则由交给cluster admin统一运维和管控，安全访问策略更容易控制。
2.PVC简化了User对存储的需求，PV才是存储的实际信息的承载体，通过kube-controller-manager中的persistentVolumeController将PVC与合适的PV bound到一起，从而满足User 对存储的实际需求。
3.PVC像是面向对对象编程中抽象出来的接口，PV是接口对应的实现。
创建PVC
PVC 的文件里存储的大小、访问模式是不变的。现在需要新加一个字段，叫 StorageClassName，它的意思是指定动态创建 PV 的模板文件的名字，这里 StorageClassName 填的就是上面声明的 csi-disk。
在提交完 PVC之后，K8s 集群中的相关组件就会根据 PVC 以及对应的 StorageClass 动态生成这块 PV 给这个 PVC 做一个绑定，之后用户在提交自己的 yaml 时，用法和接下来的流程和前面的静态使用方式是一样的，通过 PVC 找到我们动态创建的 PV，然后把它挂载到相应的容器中就可以使用了。
PVC 的 yaml 
写的是我需要的大小以及我需要的 accessModes。提交完之后，它就与我们集群中已经存在的 PV 做匹配，匹配成功之后，它就会做 bound。
PVC 的处理流程
csi 是什么？csi 的全称是 container storage interface，它是 K8s 社区后面对存储插件实现 ( out of tree ) 的官方推荐方式。
接下来看一下，当用户提交 yaml 之后，k8s 内部的处理流程。用户在提交 PVCyaml 的时候，首先会在集群中生成一个 PVC 对象，然后 PVC 对象会被 csi-provisioner controller watch 到，csi-provisioner 会结合 PVC 对象以及 PVC 对象中声明的 storageClass，通过 GRPC 调用 csi-controller-server，然后，到云存储服务这边去创建真正的存储，并最终创建出来 PV 对象。最后，由集群中的 PV controller 将 PVC 和 PV 对象做 bound 之后，这个 PV 就可以被使用了。
用户在提交 pod 之后，首先会被调度器调度选中某一个合适的node，之后该 node 上面的 kubelet 在创建 pod 流程中会通过首先 csi-node-server 将我们之前创建的 PV 挂载到我们 pod 可以使用的路径，然后 kubelet 开始 create && start pod 中的所有 container。
