PV

PV（PersistentVolume持久化卷），是对底层的共享存储的一种抽象，PV 由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如 Ceph、GlusterFS、NFS 等，都是通过插件机制完成与共享存储的对接。创建PV时可以指定access mode访问方式.

access mode

access mode 有四种：

• ReadWriteOnce:可读可写，但只支持被单个node挂载。该访问模式约束仅有一个node节点可以访问pvc。换句话来说，同一node节点的不同pod是可以对同一pvc进行读写的
• ReadOnlyMany:可以以只读的方式被多个node挂载
• ReadWriteMany:可以以读写的方式被多个node挂载
• ReadWriteOncePod：仅有一个Pod可以访问使用该pvc（Kubernetes >= v1.22）当你创建一个带有pvc访问模式为ReadWriteOncePod的Pod A时，Kubernetes确保整个集群内只有一个Pod可以读写该PVC。此时如果你创建Pod B并引用了与Pod A相同的PVC(ReadWriteOncePod)时，那么Pod B会由于该pvc被Pod A引用而启动失败。

PVC

PVC （PersistentVolumeClaim） 是由用户进行存储的请求。 它类似于pod。 Pod消耗节点资源，PVC消耗PV资源。Pod可以请求特定级别的资源（CPU和内存）。

通常运维创建PV，并指定PV访问方式（多选），开发进行PVC的资源申领，申领时根据开发指定的访问方式去匹配PV，开发申领时指定的PVC访问方式，如果在PV中找不到（PVC的access mode 不在 PV 的access mode的子集中），则PVC创建失败。

访问模式只是能力描述，并不是强制执行的，对于没有按pvc声明的方式使用pv，存储提供者应该负责访问时的运行错误。例如如果设置pvc的访问模式为ReadOnlyMany ，pod挂载后依然可写，如果需要真正的不可写，申请pvc是需要指定 readOnly: true 参数

StorageClass

大规模集群中可能会有很多PV，如果这些PV都需要运维手动来处理这也是一件很繁琐的事情，所以就有了动态供给概念，也就是Dynamic Provisioning，动态供给的关键就是StorageClass，它的作用就是创建PV模板。创建StorageClass里面需要定义PV属性比如存储类型、大小等；另外创建这种PV需要用到存储插件。最终效果是，用户提交PVC，里面指定存储类型，如果符合我们定义的StorageClass，则会为其自动创建PV并进行绑定。