Kubernetes持久卷PV详解

Kubernetes持久卷PV详解

引用

CSDN

1.

https://blog.csdn.net/be_racle/article/details/141576147

在Kubernetes中，持久卷（Persistent Volume，PV）是集群中的一块存储，由管理员预置，可以是裸磁盘、NFS共享文件系统、iSCSI目标或其他类型的存储。PV一旦创建，就成为集群的一部分，直到被销毁。PV包含了存储设备的详细信息，比如类型、访问模式、容量大小等。

《持久化存储》系列，共包含以下文章：

• K8s 持久化存储方式
• 持久卷 PV
• 持久卷声明 PVC
• 持久卷的动态供给 Dynamic Provisioning

持久卷 PV

• 1.什么是持久卷
• 2.创建一个持久卷
• 3.持久卷的访问模式
• 4.持久卷的回收策略

数据卷是在创建 Pod 时通过挂载目录来实现数据的共享和持久化的。但是在一个大型系统中，这种方式是非常不利于管理的，因为数据卷把数据的持久存储和供应使用封装在一起了那么，能否将数据的持久存储和供应使用分别进行管理和使用呢？为了解决这个问题，Kubernetes 提供了持久卷（
Persistent Volume
，
PV
）和持久化声明（
Persistent Volume Claim
，
PVC
）。

• 持久卷（
  Persistent Volume
  ，
  PV
  ）：这是集群中的一块存储，由管理员预置，可以是裸磁盘、NFS 共享文件系统、iSCSI 目标或其他类型的存储。PV 一旦创建，就成为集群的一部分，直到被销毁。PV 包含了存储设备的详细信息，比如类型、访问模式、容量大小等。

• 持久化声明（
  Persistent Volume Claim
  ，
  PVC
  ）：这是 Pod 使用者对存储资源的需求声明。PVC 定义了请求的存储量和访问模式。当一个 Pod 需要持久存储时，它会通过 PVC 来申请。Kubernetes 的调度器会尝试将 PVC 与合适的 PV 进行绑定。

PV 和 PVC 的关系：

• 🚀 PV 和 PVC 是一对多的关系，即一个 PV 可以被多个 PVC 请求，但一个 PVC 只能绑定到一个 PV 上。
• 🚀 当一个 PVC 被创建后，它会处于
  Pending
  状态，直到一个匹配的 PV 被绑定，此时状态变为
  Bound
  。
• 🚀 如果 PVC 没有找到匹配的 PV，或者 PV 的容量不足，PVC 将保持在
  Pending
  状态。
• 🚀 当 Pod 不再需要存储时，可以通过删除 PVC 来释放 PV，但 PV 本身不会自动被删除，除非设置了相应的回收策略。

这种设计允许存储资源的动态分配和回收，提高了存储资源的利用率和灵活性。

1.什么是持久卷

持久卷（
Persistent Volume
，
PV
）是 Kubernetes 集群的一种存储方式。持久卷也是集群的一种资源，可以事先创建或者通过存储类（
Storage Class
）来动态提供。

持久卷通过卷插件的形式对外部的存储资源进行操作，并可以通过指定存储回收策略来控制持久卷回收对外部存储中的数据的影响。

持久卷对象一般由 Kubernetes 集群的管理员创建。它只代表集群为用户提供的一种存储资源。至于这种存储资源如何被使用，它不需要关心。

持久卷和数据卷一样也是使用卷插件来实现的，但二者的最大区别在于：

• 持久卷与 Pod 的生命周期相互独立，它不会因为 Pod 生命周期的结束而被销毁。
• 数据卷一般与 Pod 绑定，它的生命周期与 Pod 相同。

2.创建一个持久卷

下面演示如何创建一个持久卷。

创建持久卷的描述文件
pv-demo-1.yaml
，并在其中输入以下内容。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo-1
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
- ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  nfs:
    server: 172.30.1.2
    path: /nfs

• spec.capacity
  ：用于指定持久卷的容量。上面代码中设置持久卷的容量是 5GB。

• spec.volumeMode
  ：指定持久卷的模式。Kubernetes 支持两种类型的持久卷模式：文件系统（
  File System
  ）和块存储设备（
  Raw Block Devices
  ）。

• 如果该参数没有被指定，则默认采用文件系统。

• 如果将该字段设置为块存储设备，且该存储设备为空，则 Kubernetes 会在第 1 次使用持久卷时在该设备上创建文件系统。这也是在 Pod 中以最快的速度来访问存储的方式。

• spec.accessModes
  ：指定持久卷的访问模式。通过设置持久卷的访问模式，可以让持久卷以不同的读写方式挂载到宿主系统上，从而让每个持久卷能够拥有对存储资源的读写能力。

• spec.persistentVolumeReclaimPolicy
  ：在定义持久卷时可以通过该字段指定存储资源的回收策略。该回收策略用来指定在删除持久卷或者持久卷声明时，Kubernetes 如何处理存储资源上的数据文件。

• spec.storageClassName
  ：用来设置存储类。设置了存储类的持久卷只能提供给请求该存储类的持久化声明使用。如果持久卷没有设置该字段，则该持久卷只能提供给没有存储类的持久化声明。

• spec.nfs
  ：指定持久卷的挂载选项。当 Pod 要使用持久卷时，能够指定附加的挂载选项。Kubernetes 的持久卷支持具有多种挂载选项的卷插件，如 AWSElasticBlockStore、CephFS、Cinder、NFS、RBD 等。在
  pv-demo-1.yaml
  文件中就是用 NFS（网络文件系统）作为挂载选项。

使用
kubectl apply -f
命令创建持久卷。

kubectl apply -f pv-demo-1.yaml

查看创建的持久卷信息。

kubectl get pv

输出的信息如下：

🚀 这里的 STATUS 是
Available
，表示该持久卷还没有被挂载使用。

获取持久卷的详细信息。

kubectl describe pv pv-demo-1

输出的信息如下：

3.持久卷的访问模式

持久卷可以使用不同的存储资源，以所支持的任何方式挂载到宿主系统上。每个持久卷都会有自身的访问模式以描述持久卷的读写能力。

spec.accessModes
字段用于指定持久卷的访问式。

下表列出了 Kubernetes 所支持的持久卷访问模式。

🚀 持久卷支持多种访问模式，但在同一个时刻只能使用一种访问模式挂载。例如，一个 NFS 的持久卷对象在某一个时刻可以被 node 节点以
ReadWriteOnce
访问模式挂载，或者被多个 node 节点以
ReadOnlyMany
访问模式挂载，但不允许同时使用两种及以上的访问模式挂载。

下表是 Kubernetes 官方提供的持久卷的不同卷插件所支持的访问模式。

4.持久卷的回收策略

在定义持久卷时，可以通过
persistentVolumeReclaimPolicy
字段来指定存储资源的回收策略。

目前 Kubernetes 的持久卷回收策略有以下 3 种。

• Retain
  ：该回收策略允许用户手动执行回收资源的操作。在删除 PVC 对象时，PV 对象不会被真的删除，只是 PV 对象的状态会变成 Released。因为用户数据仍然存在于 PV 对象的存储资源中，所以，该 PV 对象暂时还不能够提供给其他 PVC 对象使用。管理员必须在删除旧的 PV 对象并清理对应的存储资源后，才可以创建新的 PV 对象继续使用。如果存储资源中有非常重要的数据，推荐使用这种回收策略。

• Delete
  ：该回收策略在删除 PersistentVolumeClaim 时，会自动从 Kubernetes 中删除对应的 PV 对象，以及外部存储的资源。该回收策略也是持久卷动态供给时 PV 对象的默认回收策略。

• Recycle
  ：该回收策略在删除 PV 对象时，会对持久卷执行清除操作（即执行
  rm -rf /thevolume/*
  命令）。通过这样方式回收的 PV 对象，可以再次用来处理新的 PVC 对象的申请。

下面来演示不同回收策略的行为特征。

由于持久卷
pv-demo-1
对象使用的是 NFS 存储方式，因此首先到 master 节点的 NFS Server 上创建一些测试文件。

cd /nfs/
echo hello world > data.txt

创建
pv-demo-1
对象。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo-1
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
- ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  nfs:
    server: 172.30.1.2
    path: /nfs

创建
pvc-demo-1
对象。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo-1
spec:
  accessModes:
- ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  storageClassName: slow

kubectl apply -f pv-demo-1.yaml
kubectl apply -f pvc-demo-1.yaml

查看 PV 和 PVC 的信息。

kubectl get pv,pvc

🚀 可以看出，
pv-demo-1
对象的回收策略是Recycle。这意味着：在删除
pvc-demo-1
对象时，会对
pv-demo-1
对象执行清空操作，把持久卷存储的数据彻底删除，即执行
rm -rf /nfs
命令。这时并不会删除
pv-demo-1
对象，只是其状态将由
Bound
变成
Available
。

修改
pv-demo-1
对象的回收策略为Retain。

kubectl patch pv pv-demo-1 -p '{"spec": {"persistentVolumeReclaimPolicy": "Retain"}}'

删除
pvc-demo-1
对象。

kubectl delete persistentvolumeclaim/pvc-demo-1

查看 PV 和 PVC 对象的信息，这时
pv-demo-1
对象的状态将由
Bound
变成
Available
。

kubectl get pv,pvc

输出的信息如下：

🚀Retain回收策略不会对外部的存储资源执行清空操作，因此这时 master 节点的 NFS Server 上的数据依然存在。检查 master 节点的
/nfs
目录：

ls /nfs/
more /nfs/data.txt