pv和pvc

一、PV和PVC详解

当前，存储的方式和种类有很多，并且各种存储的参数也需要非常专业的技术人员才能够了解。在Kubernetes集群中，放了方便我们的使用和管理，Kubernetes提出了PV和PVC的概念，这样Kubernetes集群的管理人员就可以将注意力集中到Kubernetes集群中来，而无需操心后端的存储设备。

pv : 相当于磁盘分区

pvc: 相当于磁盘请求

PersistentVolumeClaim（PVC）是用户存储的请求

PVC的使用逻辑：在pod中定义一个存储卷（该存储卷类型为PVC），

定义的时候直接指定大小，pvc必须与对应的pv建立关系，

pvc会根据定义去pv申请，而pv是由存储空间创建出来的。

pv和pvc是kubernetes抽象出来的一种存储资源。

PV : 持久化卷的意思，是对底层的共享存储的一种抽象

PVC（Persistent Volume Claim）是持久卷请求于存储需求的一种声明(PVC其实就是用户向kubernetes系统发出的一种资源需求申请。)

从上图可以看出，底层的存储可以使各种类型，包括NFS、Ceph、CIFS等等，而Kubernetes会把这些存储统一抽象为PV。PV，即Persistent Volume，是集群中配置的存储资源。PVC，即Persistent Volume Claim，是用户存储的请求，通常我们在一个Pod中定义一个存储卷，定义的时候会指定该存储卷的相关信息，比如空间大小、可读可写等属性。但是PVC并不是真正的存储空间，Pod的PVC和PV之间必须建立某种联系，这样才能使得Pod可以调用实际存储空间。

kind: PersistentVolume
metadata:
  name: pv2
apiVersion: v1  
spec:
  nfs: # 存储类型，与底层真正存储对应
  capacity:  # 存储能力，目前只支持存储空间的设置
    storage: 2Gi
  accessModes:  # 访问模式
  storageClassName: # 存储类别
  persistentVolumeReclaimPolicy: # 回收策略

使用了PV和PVC之后，工作可以得到进一步的细分：

存储：存储工程师维护

PV： kubernetes管理员维护

PVC：kubernetes用户维护

二、PV和PVC生命周期

实际上，不管是PV，还是PVC，都遵循以下生命周期：

2.1 Provisioning

Provisioning，即配置阶段。一般而言，PV的提供方式有两种——静态和动态。

所谓静态提供，就是Kubernetes管理员创建多个PV，这些PV的存储空间等属性已经确定，并且已经和真实的存储设备进行了关联。Pod中的PVC可以根据需要请求这些PV。

所谓动态提供，需要依托与StorageClass的支持，这时Kubernetes会尝试为PVC来动态的创建PV。这样做的好处是避免出现这种情况：部分PVC被分配给了远远超出其资源需求的PV、或者说系统存在很多资源较少的PV，但是一个资源需求很高的PVC缺无法被满足的情况。

2.2 Binding

在动态配置的情况下，用户创建或者已经创建了具有特定数量的PVC后，PVC与PV绑定的过程。

如果没有满足PVC请求需求的PV，那么PVC将无法被创建，因此造成的结果就是相应的Pod也不会被创建。

2.3 Using

即PVC与PC绑定后，Pod对存储空间的使用过程。

2.4 Releasing

当Pod被删除或者对该PV的资源使用结束后，Kubernetes就会删除该PVC对象，相应的也会回收PV资源，这时的PV就会处于这种状态。但是此时的PV还需要处理完毕之前的Pod在该存储卷上存储信息后才能够被使用。

2.5 Reclaiming

PV的回收策略对被释放的PV的处理过程。

2.6 Recycling

根据配置，有时PV会被执行擦除操作，删除掉该存储空间上的所有信息，并且该存储资源也可以被再次使用。

三、访问模式

3.1 PV 的访问模式（accessModes）

模式	解释
ReadWriteOnce （RWO）	可读可写，但只支持被单个节点挂载。
ReadOnlyMany (ROX)	只读，可以被多个节点挂载。
ReadWriteMany (RWX)	多路可读可写。这种存储可以以读写的方式被多个节点共享。不是每一种存储都支持这三种方式，像共享方式，目前支持的还比较少，比较常用的是 NFS。在PVC绑定PV时通常根据两个条件来绑定，一个是存储的大小，另一个就是访问模式。

3.2 PV的回收策略（persistentVolumeReclaimPolicy）