二十二、PV和PVC-优快云博客

本文链接：https://blog.youkuaiyun.com/Cyan_Jiang/article/details/144653749

The calm, not indifferent, contend for the inevitable, let it be.
得之坦然，失之淡然，争其必然，顺其自然

概述

PersistentVolume（PV）和Persistent Volume Claim（PVC）

PV（持久卷）是对存储资源的抽象，将存储定义为一种容器应用可以使用的资源。PV由管理员创建和配置，它与存储提供商的具体实现直接相关，例如GlusterFS、iSCSI、RBD或GCE或AWS公有云提供的共享存储，通过插件式的机制进行管理，供应用访问和使用。除了EmptyDir类型的存储卷，PV的生命周期独立于使用它的Pod。

PVC则是用户对存储资源的一个申请。就像Pod消耗Node的资源一样，PVC消耗PV资源。PVC可以申请存储空间的大小（size）和访问模式（例如ReadWriteOnce、ReadOnlyMany或ReadWriteMany）。

可以将PV看作可用的存储资源，PVC则是对存储资源的需求

在这里插入图片描述
Kubernetes支持两种资源供应模式：静态模式（Static）和动态模式（Dynamic），资源供应的结果就是将适合的PV与PVC成功绑定。

◎ 静态模式：集群管理员预先创建许多PV，在PV的定义中能够体现存储资源的特性。
◎ 动态模式：集群管理员无须预先创建PV，而是通过StorageClass的设置对后端存储资源进行描述，标记存储的类型和特性。用户通过创建PVC对存储类型进行申请，系统将自动完成PV的创建及与PVC的绑定。如果PVC声明的Class为空" "，则说明PVC不使用动态模式。

静态资源：
在这里插入图片描述

动态资源：

在这里插入图片描述
如果资源供应使用的是动态模式，则系统在为PVC找到合适的StorageClass后，将自动创建一个PV并完成与PVC的绑定。

存储资源（PV、PVC）相对于容器应用（Pod）是独立管理的资源，可以单独删除。在做删除操作的时候，系统会检测存储资源当前是否正在被使用，如果仍被使用，则对相关资源对象的删除操作将被推迟，直到没被使用才会执行删除操作，这样可以确保资源仍被使用的情况下不会被直接删除而导致数据丢失。这个机制被称为对使用中的存储对象的保护机制（Storage Object in Use Protection）。

一、为什么用PV和PVC

只有Volume无法满足生产需求，所以要有pv

在这里插入图片描述

Volume无法解决的问题：

➢ 当某个数据卷不再被挂载使用时，里面的数据如何处理？

➢ 如果想要实现只读挂载如何处理？

➢ 如果想要只能一个Pod挂载如何处理？

➢ 如何只允许某个Pod使用10G的空间？

PersistentVolume：

简称PV，是由Kubernetes管理员设置的存储，可以配置Ceph、NFS、GlusterFS等常用存储配置，相对于Volume配置，提供了更多的功能，比如生命周期的管理、大小的限制。PV分为静态和动态。

PersistentVolume（PV）是群集中的一块存储，由管理员配置或使用存储类动态配置。它是集群中的资源，就像 pod 是 k8s 集群资源一样。 PV 是容量插件，如 Volumes，其生命周期独立于使用 PV 的任何单个 pod。

PersistentVolumeClaim：

简称PVC，是对存储PV的请求，表示需要什么类型的PV，需要存储的技术人员只需要配置PVC即可使用存储，或者Volume配置PVC的名称即可。

PersistentVolumeClaim（PVC）是一个持久化存储卷，我们在创建 pod 时可以定义这个类型的存储卷。它类似于一个 pod。 Pod 消耗节点资源，PVC 消耗 PV 资源。 Pod 可以请求特定级别的资源（CPU 和内存）。 pvc 在申请 pv 的时候也可以请求特定的大小和访问模式（例如，可以一次读写或多次只读）。

1、PVC 和 PV 工作原理

PV 是群集中的资源。 PVC 是对这些资源的请求。PV 和 PVC 之间的相互作用遵循以下生命周期：

（1）pv 的供应方式
可以通过两种方式配置 PV：静态或动态。

静态的：
集群管理员创建了许多 PV。它们包含可供群集用户使用的实际存储的详细信息。它们存在于Kubernetes API 中，可供使用。

动态的：
当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，群集可能会尝试为 PVC 专门动态配置卷。此配置基于 StorageClasses，PVC 必须请求存储类，管理员必须创建并配置该类，以便进行动态配置。

（2）绑定
用户创建 pvc 并指定需要的资源和访问模式。在找到可用 pv 之前，pvc 会保持未绑定状态

（3）使用

1. 需要找一个存储服务器，把它划分成多个存储空间；
1. k8s 管理员可以把这些存储空间定义成多个 pv；
1. 在 pod 中使用 pvc 类型的存储卷之前需要先创建 pvc，通过定义需要使用的 pv 的大小和对应的访问模式，找到合适的 pv；
1. pvc 被创建之后，就可以当成存储卷来使用了，我们在定义 pod 时就可以使用这个 pvc 的存储卷
1. pvc 和 pv 它们是一一对应的关系，pv 如果被 pvc 绑定了，就不能被其他 pvc 使用了；
1. 在创建 pvc 的时候，应该确保和底下的 pv 能绑定，如果没有合适的 pv，那么 pvc 就会处于 pending 状态。

（4）回收策略
当我们创建 pod 时如果使用 pvc 做为存储卷，那么它会和 pv 绑定，当删除 pod，pvc 和pv 绑定就会解除，解除之后和 pvc 绑定的 pv 卷里的数据需要怎么处理，目前，卷可以保留，回收或删除：

Recycle （不推荐使用，1.15 可能被废弃了）
Retain

当删除 pvc 的时候，pv 仍然存在，处于 released 状态，但是它不能被其他 pvc 绑定使用，里面的数据还是存在的，当我们下次再使用的时候，数据还是存在的，这个是默认的回收策略
Delete

删除 pvc 时即会从 Kubernetes 中移除 PV，也会从相关的外部设施中删除存储资产

官方文档：https://kubernetes.io/docs/concepts/storage/persistent-volumes/

在这里插入图片描述

PV 没有命名空间限制
PVC 有命名空间限制

二、回收和访问策略

更灵活的存储配置

1、PV回收策略

官方文档：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#reclaim-policy

Retain：保留，该策略允许手动回收资源，当删除PVC时，PV仍然存在，PV被视为已释放，管理员可以手动回收卷。多用于静态。
Recycle：回收，如果Volume插件支持，Recycle策略会对卷执行rm -rf清理该PV，并使其可用于下一个新的PVC，但是本策略将来会被弃用，目前只有NFS和HostPath支持该策略。
Delete：删除，如果Volume插件支持，删除PVC时会同时删除PV，动态卷默认为Delete，目前支持Delete的存储后端包括AWS EBS, GCE PD, Azure Disk, or OpenStack Cinder等。多用于动态。
可以通过persistentVolumeReclaimPolicy: Recycle字段配置

2、PV访问策略

官方文档：https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

ReadWriteOnce：可以被单节点以读写模式挂载，命令行中可以被缩写为RWO。
ReadOnlyMany：可以被多个节点以只读模式挂载，命令行中可以被缩写为ROX。
ReadWriteMany：可以被多个节点以读写模式挂载，命令行中可以被缩写为RWX。
ReadWriteOncePod ：只允许被单个Pod访问，需要K8s 1.22+以上版本，并且是CSI创建的PV才可使用

支持列表

在这里插入图片描述

三、存储分类

文件存储：一些数据可能需要被多个节点使用，比如用户的头像、用户上传的文件等，实现方式：NFS、NAS、FTP、CephFS等。
块存储：一些数据只能被一个节点使用，或者是需要将一块裸盘整个挂载使用，比如数据库、Redis等，实现方式：Ceph、GlusterFS、公有云。
对象存储：由程序代码直接实现的一种存储方式，云原生应用无状态化常用的实现方式，实现方式：一般是符合S3协议的云存储，比如AWS的S3存储、Minio、七牛云等。直接去连接，不需要挂载，程序代码直接写文件的操作。

四、PV配置示例-NFS/NAS

部署NFS服务

NFS服务器安装服务端：#  yum install nfs* rpcbind -y
所有K8s节点安装NFS客户端：# yum install nfs-utils -y
NFS服务端：# mkdir /data/k8s -p
NFS服务器创建共享目录：# vim /etc/exports

/data/k8s/ *(rw,sync,no_subtree_check,no_root_squash)
/data/nfs/ 10.1.3.0/24(rw,sync,no_subtree_check,no_root_squash)

# exportfs -r
# systemctl restart nfs rpcbind

挂载测试,测试完再卸载：
# mount -t nfs 10.1.3.34:/data/k8s /mnt/
# cd
# umount /mnt/

生产环境不推荐NFS，会有单点故障

编写yaml文件

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-nfs                         # pv的名字，注意不是pvc绑定的名字
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs-slow           # pvc绑定的名字
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /data/k8s
    server: 10.1.3.34
    


# ➢ capacity：容量配置,storage 并不能控制大小，主要还是后端存储控制
# ➢ volumeMode：卷的模式，目前支持Filesystem（文件系统） 和 Block（块），其中Block类型需要后端存储支持，默认为文件系统
# ➢ accessModes：该PV的访问模式<