数据卷是在创建 Pod 时通过 挂载目录 来实现数据的共享和持久化的。但是在一个大型系统中，这种方式是非常不利于管理的，因为数据卷把数据的 持久存储 和 供应使用 封装在一起了那么，能否将数据的 持久存储 和 供应使用 分别进行管理和使用呢？为了解决这个问题，Kubernetes 提供了 持久卷（Persistent Volume，PV）和 持久化声明（Persistent Volume Claim，PVC）。
1.什么是持久卷
持久卷（Persistent Volume，PV）是 Kubernetes 集群的一种存储方式。持久卷也是集群的一种资源，可以事先创建或者通过存储类（Storage Class）来动态提供。
持久卷通过 卷插件 的形式对外部的存储资源进行操作，并可以通过指定 存储回收策略 来控制持久卷回收对外部存储中的数据的影响。
持久卷对象一般由 Kubernetes 集群的 管理员 创建。它只代表集群为用户提供的一种存储资源。至于这种存储资源如何被使用，它不需要关心。
持久卷和数据卷一样也是使用卷插件来实现的，但二者的最大区别在于：
- 持久卷与 Pod 的生命周期相互独立，它不会因为 Pod 生命周期的结束而被销毁。
- 数据卷一般与 Pod 绑定，它的生命周期与 Pod 相同。
2.创建一个持久卷
下面演示如何创建一个持久卷。
创建持久卷的描述文件 pv-demo-1.yaml，并在其中输入以下内容。
apiVersion: v1
kind: PersistentVolume
metadata:name: pv-demo-1
spec:capacity:storage: 5GivolumeMode: FilesystemaccessModes:- ReadWriteManypersistentVolumeReclaimPolicy: RecyclestorageClassName: slownfs:server: 172.30.1.2path: /nfs
spec.capacity：用于指定持久卷的 容量。上面代码中设置持久卷的容量是 5GB。spec.volumeMode：指定持久卷的 模式。Kubernetes 支持两种类型的持久卷模式：文件系统（File System）和 块存储设备（Raw Block Devices）。- 如果该参数没有被指定，则默认采用文件系统。
- 如果将该字段设置为块存储设备，且该存储设备为空，则 Kubernetes 会在第 1 次使用持久卷时在该设备上创建文件系统。这也是在 Pod 中以最快的速度来访问存储的方式。
spec.accessModes：指定持久卷的 访问模式。通过设置持久卷的访问模式，可以让持久卷以不同的读写方式挂载到宿主系统上，从而让每个持久卷能够拥有对存储资源的读写能力。spec.persistentVolumeReclaimPolicy：在定义持久卷时可以通过该字段指定 存储资源的回收策略。该回收策略用来指定在删除持久卷或者持久卷声明时，Kubernetes 如何处理存储资源上的数据文件。spec.storageClassName：用来设置 存储类。设置了存储类的持久卷只能提供给请求该存储类的 持久化声明 使用。如果持久卷没有设置该字段，则该持久卷只能提供给没有存储类的 持久化声明。spec.nfs：指定持久卷的 挂载选项。当 Pod 要使用持久卷时，能够指定附加的挂载选项。Kubernetes 的持久卷支持具有多种挂载选项的卷插件，如 AWSElasticBlockStore、CephFS、Cinder、NFS、RBD 等。在pv-demo-1.yaml文件中就是用 NFS（网络文件系统）作为挂载选项。
使用 kubectl apply -f 命令创建持久卷。
kubectl apply -f pv-demo-1.yaml
查看创建的持久卷信息。
kubectl get pv
输出的信息如下：
🚀 这里的 STATUS 是
Available，表示该持久卷还没有被挂载使用。
获取持久卷的详细信息。
kubectl describe pv pv-demo-1
输出的信息如下：
3.持久卷的访问模式
持久卷可以使用不同的存储资源，以所支持的任何方式挂载到宿主系统上。每个持久卷都会有自身的访问模式以描述持久卷的读写能力。spec.accessModes 字段用于指定持久卷的访问式。
下表列出了 Kubernetes 所支持的持久卷访问模式。
| 访问模式 | 命令行的缩写形式 | |
|---|---|---|
ReadWriteOnce | RWO | 持久卷可以被一个 node 节点以 读写 方式挂载，同时也允许运行在同一个 node 节点上的不同 Pod 访问该持久卷 |
ReadOnlyMany | ROX | 持久卷可以同时被多个 node 节点以 只读 方式挂载 |
ReadWriteMany | RWX | 持久卷可以同时被多个 node 节点以 读写 方式挂载 |
ReadWriteOncePod | RWOP | 持久卷只能被单个 Pod 以 读写 方式挂载。通过这种方式，可以保证在整个集群中只有一个 Pod 可以读写该持久卷 |
🚀 持久卷支持多种访问模式，但在同一个时刻只能使用一种访问模式挂载。例如，一个 NFS 的持久卷对象在某一个时刻可以被 node 节点以
ReadWriteOnce访问模式挂载，或者被多个 node 节点以ReadOnlyMany访问模式挂载，但不允许同时使用两种及以上的访问模式挂载。
下表是 Kubernetes 官方提供的持久卷的不同卷插件所支持的访问模式。
| 卷插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod |
|---|---|---|---|---|
| AWSElasticBlockStore | ✅ | |||
| AzureFile | ✅ | ✅ | ✅ | |
| AzureDisk | ✅ | |||
| CephFS | ✅ | ✅ | ✅ | |
| Cinder | ✅ | |||
| CSI | 取决于驱动程序 | 取决于驱动程序 | 取决于驱动程序 | 取决于驱动程序 |
| FC | ✅ | ✅ | ||
| FlexVolume | ✅ | ✅ | ||
| Flocker | ✅ | |||
| GCEPersistentDisk | ✅ | ✅ | ||
| Glusterfs | ✅ | ✅ | ✅ | |
| HostPath | ✅ | |||
| iSCSI | ✅ | ✅ | ||
| Quobyte | ✅ | ✅ | ✅ | |
| NFS | ✅ | ✅ | ✅ | |
| RBD | ✅ | ✅ | ||
| VsphereVolume | ✅ | Pod 运行于同一节点上时可行 | ||
| PortworxVolume | ✅ | ✅ | ||
| SorageOS | ✅ |
4.持久卷的回收策略
在定义持久卷时，可以通过 persistentVolumeReclaimPolicy 字段来指定 存储资源的回收策略。
目前 Kubernetes 的持久卷回收策略有以下 3 种。
Retain：该回收策略允许用户手动执行回收资源的操作。在删除 PVC 对象时，PV 对象不会被真的删除，只是 PV 对象的状态会变成 Released。因为用户数据仍然存在于 PV 对象的存储资源中，所以，该 PV 对象暂时还不能够提供给其他 PVC 对象使用。管理员必须在删除旧的 PV 对象并清理对应的存储资源后，才可以创建新的 PV 对象继续使用。如果存储资源中有非常重要的数据，推荐使用这种回收策略。Delete：该回收策略在删除 PersistentVolumeClaim 时，会自动从 Kubernetes 中删除对应的 PV 对象，以及外部存储的资源。该回收策略也是 持久卷动态供给 时 PV 对象的默认回收策略。Recycle：该回收策略在删除 PV 对象时，会对持久卷执行清除操作（即执行rm -rf /thevolume/*命令）。通过这样方式回收的 PV 对象，可以再次用来处理新的 PVC 对象的申请。
下面来演示不同回收策略的行为特征。
由于持久卷 pv-demo-1 对象使用的是 NFS 存储方式，因此首先到 master 节点的 NFS Server 上创建一些测试文件。
cd /nfs/
echo hello world > data.txt
创建 pv-demo-1 对象。
apiVersion: v1
kind: PersistentVolume
metadata:name: pv-demo-1
spec:capacity:storage: 5GivolumeMode: FilesystemaccessModes:- ReadWriteManypersistentVolumeReclaimPolicy: RecyclestorageClassName: slownfs:server: 172.30.1.2path: /nfs
创建 pvc-demo-1 对象。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-demo-1
spec:accessModes:- ReadWriteManyresources:requests:storage: 1GistorageClassName: slow
kubectl apply -f pv-demo-1.yaml
kubectl apply -f pvc-demo-1.yaml
kubectl get pv,pvc
🚀 可以看出，
pv-demo-1对象的回收策略是 Recycle。这意味着：在删除pvc-demo-1对象时，会对pv-demo-1对象执行清空操作，把持久卷存储的数据彻底删除，即执行rm -rf /nfs命令。这时并不会删除pv-demo-1对象，只是其状态将由Bound变成Available。
修改 pv-demo-1 对象的回收策略为 Retain。
kubectl patch pv pv-demo-1 -p '{"spec": {"persistentVolumeReclaimPolicy": "Retain"}}'
删除 pvc-demo-1 对象。
kubectl delete persistentvolumeclaim/pvc-demo-1
查看 PV 和 PVC 对象的信息，这时 pv-demo-1 对象的状态将由 Bound 变成 Available。
kubectl get pv,pvc
输出的信息如下：
🚀 Retain 回收策略不会对外部的存储资源执行清空操作，因此这时 master 节点的 NFS Server 上的数据依然存在。检查 master 节点的
/nfs目录：
ls /nfs/
more /nfs/data.txt
