【云原生kubernetes】k8s存储PV与PVC使用详解

一、前言

在整个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 文件，可以看到对应的文件已经产生了；