PersistentVolume(PV存储卷) 是集群中的一块存储空间,由集群管理员管理或者由Storage class(存储类)自动管理,PV和Pod,deployment，service 一样，都是一个资源对象
既然有了PV概念,PVC(PersistentVolumeClaim) 也说明下,PVC代表用户使用存储的请求，应用申请PV持久化空间的一个申请、声明。K8S集群可能会有多个PV,需要不停的为不同的应用创建多个PV。
比如: Pod是消耗node节点的计算资源,而PVC 存储券声明是消耗PV的存储资源。Pod可以请求的是特定数量的计算资源(CPU或内存等),而PVC 请求的是特定大小或特定访问模式(只能被单节点读写/可被多节点只读/可与被多节点读写)的存储资源。
PV和PVC 关系
PV(存储卷)和PVC(存储卷声明)关系如下图：
image.png
1. PV 是集群中的存储资源,通常是由集群管理员创建和管理
2. StorageClass 用于对PV进行分类,如果配置正常，Storage也可以根据PVC的请求动态创建PV
3. PVC 是使用该资源的请求,通常由应用程序提出请求,并指定对应的StorageClass和需求空间大小
4. PVC 可以作为数据卷的一种，被挂载到Pod中使用
存储卷(PVC)的管理过程
PV和PVC的管理过程如下：
1. 在主机上划分一个单独的目录用于PV使用,并且定义其可用大小
2. 创建PVC资源对象,以便请求PV的存储空间
3. Pod中添加数据卷,数据卷关联PVC
4. PVC 中包含容器,容器挂载数据卷
PVC配置
底层存储用NFS存储,然后NFS 目录互粉1G的容量提供PV 调度.然后通过创建PVC来申请PV的存储资源空间，最后创建Pod 测试,使用PVC声明的存储资源来实现数据的持久化。
1、搭建nfs存储
# yum -y install nfs-utils
[root@master ~]# systemctl enable rpcbind
[root@master ~]# vim /etc/exports
/nfsdata *(rw,sync,no_root_squash)
[root@master ~]# systemctl start nfs-server
[root@master ~]# systemctl enable nfs-server
[root@master ~]# showmount -e
Export list for master:
/nfsdata *
2、创建PV资源对象
# vim test-pv.yaml #编辑PV的yaml文件
apiVersion: v1
kind: PersistentVolume
metadata:
name: test-pv
spec:
capacity:
storage: 1Gi #该PV可分配的容量为1G
accessModes:
- ReadWriteOnce #访问模式为只能以读写的方式挂载到单个节点
persistentVolumeReclaimPolicy: Recycle #回收策略为Recycle
storageClassName: nfs #定义存储类名字
nfs: #这里和上面定义的存储类名字需要一致
path: /nfsdata/test-pv #指定nfs的目录
server: 192.168.20.6 #nfs服务器的IP
#关于上述的具体解释
#capacity：指定PV的大小
#AccessModes：指定访问模式
#ReadWriteOnce：只能以读写的方式挂载到单个节点（单个节点意味着只能被单个PVC声明使用）
#ReadOnlyMany：能以只读的方式挂载到多个节点
#ReadWriteMany：能以读写的方式挂载到多个节点
#persistentVolumeReclaimPolicy：PV的回收策略
#Recycle：清除PV中的数据，然后自动回收。
#Retain:需要手动回收。
#Delete：删除云存储资源。（云存储专用）
#PS：注意这里的回收策略是指，在PV被删除后，在这个PV下所存储的源文件是否删除。
#storageClassName：PV和PVC关联的依据。
[root@master ~]# kubectl apply -f test-pv.yaml #执行yaml文件
[root@master ~]# kubectl get pv test-pv #既然PV是一个资源对象，那么自然可以通过此方式查看其状态
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
test-pv 1Gi RWO Recycle Available nfs 38s
#查看PV的状态必须为Available才可以正常使用
3、创建PVC资源对象
#cat test-pvc.yaml #编写yaml文件
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: test-pvc
spec:
accessModes: #定义访问模式，必须和PV定义的访问模式一致
- ReadWriteOnce
resources:
requests:
storage: 1Gi #直接请求使用最大的容量
storageClassName: nfs #这里的名字必须和PV定义的名字一致
[root@master ~]# kubectl apply -f test-pvc.yaml #执行yaml文件
#再次查看PV及PVC的状态（状态为bound，表示该PV正在被使用）
[root@master ~]# kubectl get pvc #查看PVC的状态
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
test-pvc Bound test-pv 1Gi RWO nfs 2m10s
[root@master ~]# kubectl get pv #查看PV的状态
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
test-pv 1Gi RWO Recycle Bound default/test-pvc nfs 8m24s
4、 创建一个Pod
test-pod.yaml #编写pod的yaml文件
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: test-pod
image: busybox
args:
- /bin/sh
- -c
- sleep 30000
volumeMounts:
- mountPath: /testdata
name: volumedata #这里自定义个名称
volumes:
- name: volumedata #这里的是上面定义的名称解释，这两个名称必须一致
persistentVolumeClaim:
claimName: test-pvc
[root@master ~]# kubectl apply -f test-pod.yaml #执行yaml文件
[root@master ~]# kubectl get pod #查看pod的状态，发现其一直处于ContainerCreating状态
#怎么回事呢？
NAME READY STATUS RESTARTS AGE
test-pod 0/1 ContainerCreating 0 23s
#当遇到pod状态不正常时，一般我们可以采用三种方式来排错
#第一就是使用kubectl describe命令来查看pod的详细信息
#第二就是使用kubectl logs命令来查看pod的日志
#第三就是查看宿主机本机的message日志
#这里我采用第一种方法排错
[root@master ~]# kubectl describe pod test-pod
#输出的最后一条信息如下：
mount.nfs: mounting 192.168.20.6:/nfsdata/test-pv failed, reason given by server: No such file or directory
#原来是我们在挂载nfs存储目录时，指定的目录并不存在
#那就在nfs服务器上（这里是本机）进行创建相关目录咯
[root@master ~]# mkdir -p /nfsdata/test-pv #创建对应目录
[root@master ~]# kubectl get pod test-pod #然后再次查看pod的状态
#如果pod的状态还是正在创建，那么就是因为运行该pod的节点上的kubelet组件还没有反应过来
#如果要追求pod的启动速度，可以手动将pod所在节点的kubelet组件进行重启即可。
[root@master ~]# kubectl get pod test-pod #稍等片刻，再次查看，发现其pod已经running了
NAME READY STATUS RESTARTS AGE
test-pod 1/1 Running 0 8m
5、测试其数据持久化的效果
# kubectl exec -it test-pod /bin/sh #进入pod
/ # echo "test pv pvc" > /testdata/test.txt #向数据持久化的目录写入测试信息
#回到nfs服务器，查看共享的目录下是否有容器中写入的信息
[root@master ~]# cat /nfsdata/test-pv/test.txt #确定是有的
test pv pvc
#现在查看到pod容器的所在节点，然后到对应节点将其删除
[root@master ~]# kubectl get pod -o wide #我这里是运行在node02节点
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test-pod 1/1 Running 0 11m 10.244.2.2 node02 <none> <none>
#在node02节点查看到其pod容器的ID号，然后将其删除
[root@node02 ~]# docker ps #获取容器的ID号
[root@node02 ~]# docker rm -f dd445dce9530 #删除刚刚创建的容器
#回到nfs服务器，发现其本地目录下的数据还是在的
[root@master ~]# cat /nfsdata/test-pv/test.txt
test pv pvc
#那么现在测试，将这个pod删除，nfs本地的数据是否还在？
[root@master ~]# kubectl delete -f test-pod.yaml
[root@master ~]# cat /nfsdata/test-pv/test.txt #哦吼，数据还在
test pv pvc
#那现在要是将PVC删除呢？
[root@master ~]# kubectl delete -f test-pvc.yaml
[root@master ~]# cat /nfsdata/test-pv/test.txt #哦吼，数据不在了。
cat: /nfsdata/test-pv/test.txt: 没有那个文件或目录
总结
由于我们在创建pv这个资源对象时，采用的回收策略是清除PV中的数据，然后自动回收，而PV这个资源对象是由PVC来申请使用的，所以不管是容器也好，pod也好，它们的销毁并不会影响用于实现数据持久化的nfs本地目录下的数据，但是，一旦这个PVC被删除，那么本地的数据就会随着PVC的销毁而不复存在，也就是说，采用PV这种数据卷来实现数据的持久化，它这个数据持久化的生命周期是和PVC的生命周期是一致的。
