官网参考：
https://kubernetes.io/docs/concepts/storage/persistent-volumes/#
1、介绍
管理存储是与管理计算实例不同的问题。PersistentVolume子系统为用户和管理员提供了一个API，该API从存储的使用方式中抽象出存储是如何提供的细节。为此，我们引入了两个新的API资源：persistenvolume和persistenvolumeclaim。
1）PersistentVolume（PV）是由管理员设置的存储，它是集群中的资源，就像节点是集群资源一样。PV是类似于卷的卷插件，但它的生命周期独立于使用PV的任何单个Pod。此API对象捕获存储实现的详细信息，包括NFS、iSCSI或特定于云提供商的存储系统。
2）PersistentVolumeClaim（PVC）是用户对存储的请求。pod消耗节点资源，pvc消耗PV资源。Pods可以请求特定级别的资源（CPU和内存）。声明可以请求特定的大小和访问模式（例如，它们可以一次读/写或多次只读）。
虽然PersistentVolumeClaims允许用户使用抽象存储资源，但用户通常需要具有不同属性（如性能）的PersistentVolumes来解决不同的问题。群集管理员需要能够提供多种持久卷，这些持久卷的差异不仅仅在于大小和访问模式，而不需要向用户公开这些卷是如何实现的细节。对于这些需求，有一个StorageClass资源
2、持久卷的类型
PersistentVolume类型作为插件实现。Kubernetes目前支持以下插件：
GCEPersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、CSI、FC (Fibre Channel)、FlexVolume、Flocker、NFS、iSCSI、RBD (Ceph Block Device)、CephFS、Cinder、Glusterfs、VsphereVolume、Quobyte Volumes、HostPath、Portworx Volumes、ScaleIO Volumes、StorageOS
3、访问模式
在资源提供者支持的任何方式的主机上都可以安装一个持续卷。当在表格下面显示时，供应商将具有不同的能力，并且每个PV的存取模式被设置到由该特定卷支持的特定模式上。例如，NFS可以支持多个读取/写入客户端，但一个特定NFS PV可以作为只读光盘导出到服务器上。每个PV都有自己的存取模式集描述特异PV的能力。
访问模式如下：
RWO-readwriteonce：被单个节点装入读写
ROX-Readonlymany：被许多节点装入阅读
RWX-readwritemany：被许多节点装入阅读书写
4、生命周期
pv是集群中的资源。pvc是对这些资源的请求，也充当对资源的索赔检查，pv有两种配置方式：静态配置或动态配置。
1）静态的
群集管理器创建多个pv。它们携带真实存储的详细信息，可供集群用户使用。它们存在于Kubernetes API中，可供使用。
2）动态的
当管理员创建的静态pv与用户的PersistentVolumeClaim不匹配时，集群可能会尝试动态地为PVC提供卷。此设置基于StorageClasses：PVC必须请求一个存储类，管理员必须已创建并配置该类才能进行动态设置。请求类“”的声明有效地为自己禁用动态设置。要基于存储类启用动态存储资源调配，群集管理员需要在API服务器上启用DefaultStorageClass许可控制器。例如，可以通过确保DefaultStorageClass位于API服务器组件的--enable acceptment plugins标志的逗号分隔的、有序的值列表中来实现。有关API服务器命令行标志的更多信息，请查看kube API server文档
绑定
用户创建了一个PersistentVolumeClaim，或者在动态资源调配的情况下，已经创建了一个PersistentVolumeClaim，该PersistentVolumeClaim具有请求的特定存储量和特定的访问模式。主控中的控制循环监视新的pvc，找到匹配的PV（如果可能），并将它们绑定在一起。如果一个PV是为一个新的PVC动态配置的，那么循环将始终将该PV绑定到PVC。否则，用户将始终至少得到他们要求的内容，但容量可能超过所要求的内容。一旦绑定，PersistentVolumeClaim绑定是独占的，不管它们是如何绑定的。PVC到PV绑定是一对一映射，使用ClaimRef，ClaimRef是persistenvolume和persistenvolumeclaim之间的双向绑定。
如果不存在匹配的卷，则声明将无限期保持未绑定状态。当匹配的卷可用时，将绑定声明。例如，配置了许多50Gi pv的集群与请求100Gi的PVC不匹配。当一个100Gi的PV添加到集群时，PVC可以被绑定。
持久化声明的保护
目的是确保由pod正在使用的持久卷pvc不会从系统中删除，因为这可能会导致数据丢失。如果用户删除Pod正在使用的PVC，则不会立即删除该PVC。PVC将会去除被推迟，直到PVC不再被任何pod使用。此外，如果管理员删除绑定到PVC的PV，则不会立即删除该PV。PV移除被推迟，直到PV不再与PVC绑定。
回收策略
当用户使用完他们的卷时，他们可以从允许资源回收的API中删除PVC对象。
Retain保留:允许手动回收资源。删除PersistentVolumeClaim时，PersistentVolume仍然存在，并且该卷被视为“已释放”。
Delete删除:对于支持Delete reclaim策略的卷插件，deletion将从Kubernetes中删除PersistentVolume对象，以及外部基础结构（如AWS EBS、GCE PD、Azure磁盘或煤渣卷）中的关联存储资产。
Recycle回收:基本擦除（rm-rf/the volume/*）
警告：回收策略已弃用。相反，推荐的方法是使用动态资源调配。
状态
卷可以处于以下的某种状态：
Available（可用）：块空闲资源还没有被任何声明绑定
Bound（已绑定）：卷已经被声明绑定
Released（已释放）：声明被删除，但是资源还未被集群重新声明
Failed（失败）：该卷的自动回收失败
5、实际操作
[root@k8smaster pp]# more pv.yaml #创建PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: mypv1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: nfs
nfs:
path: /sharedir
server: 192.168.23.100
[root@k8smaster pp]# kubectl create -f pv.yaml
persistentvolume/mypv1 created
[root@k8smaster pp]# kubectl get pv #STATUS 为 Available
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Available nfs 36s
[root@k8smaster pp]#
capacity 指定PV的容量为1G。
accessModes 指定访问模式为ReadWriteOnce，支持的访问模式有：
ReadWriteOnce – PV能以read-write模式mount到单个节点。
ReadOnlyMany – PV能以read-only模式 mount到多个节点。
ReadWriteMany – PV能以read-write模式 mount 到多个节点。
persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
Retain – 需要管理员手工回收。
Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。
storageClassName 指定PV的class为 nfs。相当于为PV设置了一个分类，PVC可以指定class申请相应class的 PV。
指定 PV 在 NFS 服务器上对应的目录。
[root@k8smaster pp]# more pvc.yaml #只需要指定 PV 的容量，访问模式和 class
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mypvc1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: nfs
[root@k8smaster pp]# kubectl create -f pvc.yaml
persistentvolumeclaim/mypvc1 created
[root@k8smaster pp]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc1 Bound mypv1 1Gi RWO nfs 9s
[root@k8smaster pp]# kubectl get pv #已经 Bound 到 mypv1，申请成功
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Bound default/mypvc1 nfs 12m
[root@k8smaster pp]#
[root@k8smaster pp]# more pv-pod.yaml #使用普通Volume的格式类似，在volumes中通过persistentVolumeClaim指定使用mypvc1申请的 Volume
apiVersion: v1
kind: Pod
metadata:
name: pv-pod
spec:
containers:
- name: pv-pod-ctn
image: 192.168.23.100:5000/tomcat:v2
volumeMounts:
- name: pv-volume
mountPath: /tmp/config
volumes:
- name: pv-volume
persistentVolumeClaim:
claimName: mypvc1
restartPolicy: Never
[root@k8smaster pp]# kubectl create -f pv-pod.yaml
pod/pv-pod created
[root@k8smaster pp]# kubectl get pod
NAME READY STATUS RESTARTS AGE
pv-pod 1/1 Running 0 13s
[root@k8smaster pp]# kubectl exec -it pv-pod /bin/bash
root@pv-pod:/usr/local/tomcat# cd /tmp/config/
root@pv-pod:/tmp/config# ls -lrt
total 8
-rw-r--r-- 1 nobody nogroup 7 Feb 19 14:19 node01.log
-rw-r--r-- 1 nobody nogroup 7 Feb 19 14:19 node02.log
root@pv-pod:/tmp/config# echo "pv-pod" >pv-pod.log #在pod中创建文件
root@pv-pod:/tmp/config# ls -lrt
total 12
-rw-r--r-- 1 nobody nogroup 7 Feb 19 14:19 node01.log
-rw-r--r-- 1 nobody nogroup 7 Feb 19 14:19 node02.log
-rw-r--r-- 1 nobody nogroup 7 Feb 19 2020 pv-pod.log
[root@k8snode01 sharedir]# pwd #在nfs客户端查看生成的文件
/sharedir
[root@k8snode01 sharedir]# ls -lrt
total 12
-rw-r--r-- 1 nfsnobody nfsnobody 7 Feb 19 22:19 node01.log
-rw-r--r-- 1 nfsnobody nfsnobody 7 Feb 19 22:19 node02.log
-rw-r--r-- 1 nfsnobody nfsnobody 7 Feb 20 2020 pv-pod.log
[root@k8snode01 sharedir]# more pv-pod.log
pv-pod
[root@k8snode01 sharedir]#
[root@k8smaster pp]# kubectl delete pod pv-pod #退出pod
pod "pv-pod" deleted
[root@k8smaster pp]# kubectl delete pvc mypvc1 #删除pvc进行回收资源
[root@k8smaster pp]# kubectl get pod #当PVC mypvc1被删除后，发现Kubernetes启动了一个新Pod，这个Pod的作用就是清除PV mypv1的数据，需要busybox:1.27镜像
NAME READY STATUS RESTARTS AGE
recycler-for-mypv1 0/1 ImagePullBackOff 0 29s
[root@k8smaster pp]#
链接：https://pan.baidu.com/s/13d-i8FWF0miLx2XYNchffw #busybox:1.27镜像下载
提取码：zekc
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Failed 4m39s kubelet, k8snode02 Failed to pull image "busybox:1.27": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
Warning Failed 4m13s kubelet, k8snode02 Failed to pull image "busybox:1.27": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
Normal Scheduled 3m32s default-scheduler Successfully assigned default/recycler-for-mypv1 to k8snode02
Warning Failed 3m30s kubelet, k8snode02 Failed to pull image "busybox:1.27": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/: net/http: TLS handshake timeout
Normal Pulling 2m46s (x4 over 4m55s) kubelet, k8snode02 Pulling image "busybox:1.27"
Warning Failed 2m7s (x4 over 4m39s) kubelet, k8snode02 Error: ErrImagePull
Warning Failed 2m7s kubelet, k8snode02 Failed to pull image "busybox:1.27": rpc error: code = Unknown desc = Error response from daemon: Get https://registry-1.docker.io/v2/library/busybox/manifests/1.27: net/http: TLS handshake timeout
Normal BackOff 103s (x6 over 4m39s) kubelet, k8snode02 Back-off pulling image "busybox:1.27"
Warning Failed 89s (x7 over 4m39s) kubelet, k8snode02 Error: ImagePullBackOff
[root@k8smaster pp]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv1 1Gi RWO Recycle Available nfs 3h10m
[root@k8snode01 sharedir]# ls -lrt #删除pvc后，磁盘文件被清理删除
total 0
[root@k8snode01 sharedir]#
