Openshift中对于数据持久化的实现是利用kubernates的persistence volume框架,在kubernates中的这个persistence volume子系统则为集群用户和管理员提供了一套API，这套API对底层的持久化存储进行了封装。并提供了两个API资源对象，分别是PersistenceVolume和PersistenceVolumeClaim。
PersistenceVolume（PV）
在一个openshift集群确切的说应该是一个kubernates集群中，一个PV对象代表了集群中一块存储资源。这个存储资源是由集群管理员在搭建集群是统一创建的。（截图）
pv有一些特点：
1.集群使用者可以在不知道底层具体是怎样实现的情况下来申请和使用pv资源。
2.PV资源在被绑定之前不属于任何project，它可以被整个集群共享不存在namespace的隔离。
3.每一个PV都有它自己的生命周期。而且这个生命周期是独立于使用这块PV的pod得生命周期的，也就是说他们是互不相干的。
4.PV这个API对象就包含了底层实现持久化存储的所有细节。比如存储类型。存储空间等。
（storage asset）
3.each PV contains a spec and status
access mode
RWO(ReadOnlyOnce)：PV被绑定之后，只允许集群当中单一节点来读写。这个once代表的不是只能被读写一次。
ROX(ReadOnlyMany): 表示多个节点对pv进行只读操作。
RWX(ReadWriteMany): 支持多个节点读写操作。
PersistenceVolumeClaim（PVC）
一个PVC代表了一个集群用户对特定存储资源的一次请求。
如同pod消耗cpu和内存资源，pvc消耗的是pv资源。
这与集群中的pod很相似，运行在集群中的pod在被定义的时候可以指定这个POD需要消耗多少node节点的资源比如说CPU和内存。同理，一个PVC可以根据定义的access model 和 storage class 来消耗特定的PV资源。
Lifecycle of volume and claim
Provisioning
- static:
由集群管理员在初始化集群时提前创建好对所有集群用户可用的 PV资源。
- dynamic:
当静态PV资源无法匹配用户的使用请求时，集群可能会尝试动态地提供一个满足这个特定PVC要求的volume，这种供给方式是基于storageClass的，也就是说，这个特定的PVC的配置信息中必须包含对一个特定storageClass的请求，并且集群管理员已经提前创建并配置到集群中的PV中，两个条件缺一不可。
如果PVC的配置信息中storageClass没有或者是“”的话，那么这个动态供给的功能就会被disable掉，这个claim会一直保留在集群中，直到一块满足它条件的静态PV资源被创建并且可用的时候，这个PVC才会被绑定。
Binding
当用户创建了一个带上指定存储空间以及访问模式（AccessMode）以及可能存在的storageClass的PVC后，会有运行在master节点上的一个服务来监测这些PVC，他们会去寻找集群中现存可用的，且匹配PVC中的条件的PVs资源，还有可能就是一个PV资源是通过动态供给的方式创建的，就将他们绑定在一起。
另外，集群总会满足用户申请的最小需求，也就说，集群最终根据PVC分配给用户的PV资源总是大于等于用户的实际需求的。当没有一个匹配的可用的PV存在于集群中时，一个claim会一直保持unbound状态直到匹配的PV资源出现。
Using
Pods use claims as volumes. The cluster inspects the claim to find the bound volume and mounts that volume for a pod. For those volumes that support multiple access modes, the user specifies which mode is desired when using their claim as a volume in a pod.
在openshift集群中，pod会把一个PVC当做一个Volume来使用，也就是说如果我们想给一个pod挂载一个数据卷作为持久化存储的工具的话，我们需要在pod的配置文件中指定persistence volume claim的配置，集群会通过这个配置找到指定的PVC，进而寻找匹配的PV资源与其绑定，在一个pod使用一个PVC（PV）的过程中，这个特定的PV资源是一直绑定给这个pod的，不会被分配给其他pod。
Releasing
当用户不在需要分配给他的volume时，用户可以通过API将这个PVC资源对象删除，删除之后这个PVC所对应的PV资源会处于released收状态，暂时不可以被集群中的其他pvc重新申请。
Reclaiming
集群中对于released 的PV资源有两种回收策略：
- Retain:
这种reclaim policy允许集群管理员手动的对资源进行回收，具体的过程是，当一个PVC被删除的时候，PV资源虽然会从这个绑定的PVC上释放出来，但它并不会立即被删除，这个时候这个PV资源对于其他的满足条件的PVC来讲暂时还是不可用的状态。原因是上一个使用这个PV的pod存储的数据还保留在这个块PV上，这个时候集群管理员可以通过如下的步骤来手动对这块PV资源进行回收：
1.删除集群中的这个PV资源
2.清理storage asset上的数据
3.根据需求决定是否删除storage asset或是复用已有的storage asset创建新的PV
- Recycling:
recycling这种reclaim policy则比较简单粗暴，它背后实际上就是执行了一个rm -rf /volume/*的命令，并且使这个PV资源对其他的PVC立即可用，支持定制化recycle，