一、前言
在整个k8s集群中，有一些存储资源，比如说NFS、CIFS等存储，这些存储都是由集群管理人员提前去创建的，不同的存储方式不一样, 如果都掌握才可以使用，则很不方便 ；
所以在k8s中提供了新的对象资源叫做PV（Persistent Volume）和PVC（Persistent Volume Claim），更方便用户直接进行使用 ；
二、什么是PV （Persistent Volume）
pv俗称持久卷，是集群中由管理员配置的一段网络存储，它是集群的一部分资源和底层存储密切相关，对象包含存储实现的细节，即 对接NFS、CIFS等存储系统 ；
- 不同的PV会对应到不用的存储资源，这样在部署pod的时候直接调用集群内部的pv即可 ；
- PV没有命名空间隔离概念 ；
三、什么是PVC （Persistent Volume Claim）
PVC 也称作持久卷声明 ，假如存在很多PV， k8s要用PV的时候直接调用某个PV的话，那如果需要的是存储能力比较大存储资源，所以这个时候需要一个一个去对比pv，这样很耗费资源（因为要满足需求） ；
- PVC是用户存储的一种声明， PVC 可以请求特定的存储空间和访问模式，PVC 消耗的是 PV 资源 ；
- PVC必须与对应的PV建立关系，PVC会根据定义的PV去申请 ；
- 创建pod的时候会附带一个PVC的请求，PVC的请求相当于就是去寻找一个合适的pv ；
PVC 使用方式
在 pod 中定义一个存储卷（该存储卷类型为 PVC)，定义的时候按指定大小，PVC 必须与对应的 PV 建立关系，PVC 会根据定义的需求【去 PV 申请】，而 PV 是由存储空间创建出来的 ；
四、PV和PVC逻辑关系
- PV 是集群中的【资源】，PVC 是对这些【资源的请求】 ；
- PV 和 PVC 之间的相互作用遵循这个生命周期；
Provisioning(配置) ---> Binding(绑定) ---> Using(使用) ---> Releasing(释放) ---> Recycling(回收）
五、PV-yaml模板说明
如下是yaml中关于pv的一段配置
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: test-pv
-
spec:
-
capacity:
-
storage: 1Gi
#存储大小
-
accessModes:
#访问模式
-
- ReadWriteOnce
-
persistentVolumeReclaimPolicy: Recycle
#回收策略
-
storageClassName: slow
#存储类别
-
nfs:
#卷插件
-
path: /etc/nfsdata
-
server: 172.42.XX.7
接下来对模板配置中的参数做详细的说明；
存储大小
存储大小是可以设置和请求的唯一资源。 未来可能会包含 IOPS、吞吐量等属性
访问模式
用户对资源的访问权限 ，常用的权限如下：
- ReadWriteOnce（RWO）：读写权限，只能被单个节点挂载 ；
- ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载 ；
- ReadWriteMany（RWX）：读写权限，可以被多个节点挂载 ；
存储类别
- 每个 PV 可以属于某个类，通过将其 storageClassName属性设置为某个 StorageClass 的名称来指定 ；
- 特定类的 PV 卷只能绑定到请求该类存储卷的 PVC 申领；
- 未设置 storageClassName 的 PV 卷没有类设定，只能给到那些没有指定特定 存储类的 PVC 申领 ；
回收策略
当PV不再被使用了之后的处理策略 ，常用的回收策略如下：
- 保留 Retain -- 当PV对象被删除之后，与之相关的位于外部的基础设施中的数据仍然存在（如nfs），需要根据实际情况手动回收 ；
- 回收 Recycle -- 相当于在卷上执行rm -rf /volume/* 操作，之后该卷可以用于新的pvc申领 ；
- 删除 Delete -- 当PV对象被删除之后，与之相关的位于外部的基础设施中的数据也被一并删除（如nfs），需要根据实际情况手动回收，更多是云厂商设备 ；
状态
PV 的生命周期有4种不同状态
- Available（可用）——一块空闲资源还没有被任何声明绑定 ；
- Bound（已绑定）——卷已经被声明绑定 ；
- Released（已释放）——声明被删除，但是资源还未被集群重新声明 ；
- Failed（失败）——该卷的自动回收失败 ；
六、PVC-yaml模板
如下是yaml中关于pvc的一段配置，pvc相当于是资源使用的申请方，配置内容可以结合注释进行理解；
-
apiVersion: v1
-
kind: PersistentVolumeClaim
-
metadata:
-
name: test-pvc
-
namespace: default
-
spec:
-
accessModes:
# 访问模式
-
- ReadWriteMany
-
selector:
# 采用label标签对PV选择过滤
-
storageClassName:
# 存储类别，设置对应的class的PV才能被系统选出
-
resources:
# 需要存储资源的请求
-
requests:
-
storage: 1Gi
七、PV+PVC+NFS 操作演示
接下来通过一个实际案例来演示下PV+PVC+NFS的综合使用；
需求说明
- 基于NFS存储，创建2个PV ；
- 创建PVC绑定PV ；
- 创建Pod挂载PVC ；
操作步骤
1、创建nfs存储相关目录
在之前的Volume一篇中，我们讲到了关于nfs的搭建和使用，这里之间基于此nfs的服务使用即可；
创建目录
-
mkdir /opt/nfsdata/pv1
-
mkdir /opt/nfsdata/pv2
-
chmod 777 /opt/nfsdata/pv1
-
chmod 777 /opt/nfsdata/pv2
2、修改nfs配置文件
vim /etc/exports
3、重启nfs服务
systemctl restart nfs
4、创建两个PV
第一个PV的配置文件，名叫：pv1.yaml；
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: congge-pv1
-
spec:
-
capacity:
-
storage: 1Gi
-
accessModes:
-
- ReadWriteMany
-
persistentVolumeReclaimPolicy: Retain
-
nfs:
-
server: 172.31.XXX.8
-
path: /opt/nfsdata/pv1
第二个PV的配置文件，名叫：pv2.yaml；
-
apiVersion: v1
-
kind: PersistentVolume
-
metadata:
-
name: congge-pv2
-
spec:
-
capacity:
-
storage: 2Gi
-
accessModes:
-
- ReadWriteMany
-
persistentVolumeReclaimPolicy: Retain
-
nfs:
-
server: 172.31.XXX.8
-
path: /opt/nfsdata/pv2
使用apply命令进行PV的创建
-
kubectl apply -f pv1.yaml
-
kubectl apply -f pv2.yaml
5、创建PVC并使用上面的PV
在当前目录下创建一个pvc.yaml的配置文件，内容如下：
-
apiVersion: v1
-
kind: PersistentVolumeClaim
-
metadata:
-
name: congge-pvc1
-
namespace: default
-
spec:
-
accessModes:
-
- ReadWriteMany
-
resources:
-
requests:
-
storage: 1Gi
-
-
---
-
-
-
apiVersion: v1
-
kind: PersistentVolumeClaim
-
metadata:
-
name: congge-pvc2
-
namespace: default
-
spec:
-
accessModes:
-
- ReadWriteMany
-
resources:
-
requests:
-
storage: 3Gi
使用apply命令创建pvc
此时，再次查看pv的状态，可以看到pv1被pvc1绑定了，但是pv2并没有绑定，这是为什么呢？
如果此时查看pvc的状态，可以发现pvc1正好是和pv1绑定的，但是pvc2处于pending状态，这个也很好理解，因为pvc2需要的是3G的存储，但是目前没有哪个pv能够提供这样大小的存储；
要想使用到上面的2G的pv2的话，我们可以重新调整下pvc2配置中的内存大小，如下：
修改完毕后，先删除之前的pvc，然后重新创建后再次查看，这次就全部绑定上了；
六、Pod使用PVC操作演示
通过上面的步骤，我们就最终完成了两个PVC的创建，如何使用呢，其实只需要在后续创建Pod的时候使用该PVC即可；
创建一个Pod，并使用上面的PVC进行挂载
在当前目录创建一个pvc-pod.yaml的文件，配置内容如下：
-
apiVersion: v1
-
kind: Pod
-
metadata:
-
name: congge-pod1
-
namespace: default
-
spec:
-
containers:
-
- name: congge-busybox
-
image: busybox
-
command: [
"/bin/sh",
"-c",
"while true;do echo hello pvc pod1 >> /opt/print.txt; sleep 5; done;"]
-
volumeMounts:
-
- name: volume
-
mountPath: /opt/
-
volumes:
-
- name: volume
-
persistentVolumeClaim:
-
claimName: congge-pvc1
-
readOnly:
false
-
-
---
-
-
apiVersion: v1
-
kind: Pod
-
metadata:
-
name: congge-pod2
-
namespace: default
-
spec:
-
containers:
-
- name: congge-busybox
-
image: busybox
-
command: [
"/bin/sh",
"-c",
"while true;do echo hello pvc pod2 >> /opt/print.txt; sleep 5; done;"]
-
volumeMounts:
-
- name: volume
-
mountPath: /opt/
-
volumes:
-
- name: volume
-
persistentVolumeClaim:
-
claimName: congge-pvc2
-
readOnly: fals
使用apply进行Pod的创建
创建pod完成后，到nfs服务器查看相关挂载文件
进入/opt/nfsdata/pv1目录，检查是否有print.txt 文件，可以看到对应的文件已经产生了；
转载：https://blog.csdn.net/zhangcongyi420/article/details/128448910