IT评测·应用市场-qidao123.com

标题: 一文读懂K8S的PV和PVC以及实践攻略 [打印本页]

作者: 伤心客 时间: 2024-10-19 10:48
标题: 一文读懂K8S的PV和PVC以及实践攻略

博客主页：StevenZeng学堂
本文专栏: 一文读懂Kubernetes | 一文读懂Harbor | 云原生安全实战指南

❤️ 择要：作为当今最火的开源云原生体系，Kubernetes 是拥有一系列创新的组件和概念，其中最重要的组件和概念之一是 Kubernetes存储卷。Volume 组件是实现了数据持久性和共享的功能核心。本篇文章将详细介绍 Kubernetes（K8S）中的存储卷（Volume）机制，包括 Persistent Volume (PV)、Persistent Volume Claim (PVC) 和后端存储的使用，为帮助大家更好地理解三者之间的关系。

1 概念
- 1.1 什么是存储卷？
- 1.2 存储卷的类型与使用场景
- 1.3 存储类（Storage Class）
- 1.4 PV（Persistent Volume）
- 1.5 PVC (Persistent Volume Claim）
- 1.6 动态卷（Dynamic Volume Provisioning）
- 1.7 PV、PVC 与后端存储的关系
2 实战：PV 和 PVC 的部署攻略
- 2.1 实验预备
- 2.2 部署NFS Server
- 2.3 Master节点挂载测试
- 2.4 创建 PV和PVC
- 2.5 观察PV和PVC的状态
- 2.6 Pod挂载不同PVC测试
  - 2.6.1 创建Pod并挂载ReadWriteOnce的PV
  - 2.6.2 创建Pod并挂载ReadWriteOncePod的PV
  - 2.6.3 创建Pod并挂载ReadWriteMany的PV
  - 2.6.4 创建Pod并挂载ReadOnlyMany的PV
- 2.7 PV的接纳策略测试
  - 2.7.1 手动删除并接纳卷
3 总结
4 参考文献

1 概念

1.1 什么是存储卷？

在容器化环境中，因为容器的生命周期是临时的，所以伴随产生的数据默认也是临时的。当容器重启或瓦解后，其内部数据将丢失。因此，Kubernetes 引入了存储卷（Volume），为应用提实现数据持久化的能力。
1.2 存储卷的类型与使用场景

存储类型描述适用场景emptyDirPod 生命周期内的临时存储适合临时数据存储，如缓存、临时文件等。hostPath将宿主机上的文件体系目次挂载到Pod中。适用于需要访问宿主机文件体系的场景，但大概会带来宿主机与Pod间的紧耦合问题，影响Pod的调度机动性。NFS使用网络文件体系协议进行数据共享，适合多Pod之间共享数据。多个 Pod 共享访问同一文件，适合数据共享、日志网络等。块存储直接使用云服务提供的块存储，支持动态创建和挂载。适合在云上部署的生产环境，支持持久性和主动扩展。分布式文件体系这些分布式文件体系适合在高可用性和大规模集群中使用，提供更好的性能和冗余支持。企业级应用、大数据处理等场景。 1.3 存储类（Storage Class）

在 Kubernetes 中，存储类是一个抽象，让用户无需提前预备 PV，而是根据需要由集群主动分配存储。StorageClass 决定了怎样创建、设置和管理存储卷（如云盘、本地盘、NFS 等），实现按需动态分配。
简单来说，StorageClass就是一个存储策略模板，用户通过它告诉 Kubernetes：“我需要的存储资源符合这些规则，请帮我动态生成合适的存储卷。”
1.4 PV（Persistent Volume）

PV 是集群中的一个存储资源，可以由管理员创建或使用存储类动态创建，并定义了存储容量、访问模式、后端存储等规则。
以下是PV的特性：

生命周期独立于 Pod，不会因为 Pod 删除而消失。
PV 是集群级的资源，管理员负责创建。
支持多种存储类型，如本地磁盘、NFS、Cephfs等。
支持不同的访问模式，如 ReadWriteOnce（一次只能一个 Pod 写入）和 ReadWriteMany（多个 Pod 可同时写入）。

1.5 PVC (Persistent Volume Claim）

PVC 是用户对持久存储的哀求声明，它规定了存储容量和访问权限等需求，并以一种抽象方法关照Kubernetes 集群，再由Kubernetes 主动匹共同适的 PV，并进行绑定。这样对用户屏蔽了后端存储，实现存储同一管理。
以下是PVC的特性：

PVC 解耦了应用与存储资源，使开发人员不需要直接处理具体的存储细节。
如果没有符合条件的 PV，PVC 会处于“待绑定”状态，直到管理员创建满足条件的 PV。
PVC雷同于 Pod， Pod 消耗节点资源（CPU和内存），PVC 消耗 PV 资源，通常与PV是1对1的关系。

1.6 动态卷（Dynamic Volume Provisioning）

PV由管理员提前创建提供给用户使用，称为静态卷。
当用户在提交 PVC 时，K8S 根据 StorageClass 主动创建 PV，而不需要管理员提前预备好存储卷，称为动态卷。
固然，如果要实现动态卷，必须设置存储类，否则Kubernetes无法创建PV，如果PVC设置storageClassName字段为“”，也不会主动创建动态卷。
1.7 PV、PVC 与后端存储的关系

以“租房场景”来说明StorageClass、PV、PVC 与后端存储之间的关系。

后端存储： 物业公司（如 NFS、AWS EBS 等）是全部房源的真正提供者。它们负责实际存储资源的供应，例如：云存储、NFS、本地磁盘。
StorageClass：雷同租房平台上的房型模板。它定义了不同租房规则，比如：标准单间（普通低资本存储）、豪华公寓（高性能大容量存储）、短租房（临时存储）。用户在提交租房申请（PVC）时，可以指定接纳哪种房型模板（StorageClass）。根据这个模板，平台会主动生成实际的房源（PV）。
PV：雷同已经发布到平台上的“具体房子”。每个 PV 是由后端存储提供的资源，例如：某间20平方的单人房（块存储），或某间共享公寓（文件存储）。
PVC ：租客提交的租房申请。它描述了租客盼望租到的房屋类型和条件，例如：面积（容量）、入住规则（只允许一人入住，或带宠物共住）、房型要求（公寓、小区、城中村）。Kubernetes 会根据 PVC 提交的条件，主动匹共同适的 PV。如果没有符合条件的 PV，体系会根据 StorageClass 动态生成一个 PV，并绑定给 PVC。

2 实战：PV 和 PVC 的部署攻略

❔ 说明：以NFS作为后端存储，验证PV和PVC相关策略。
2.1 实验预备

nfs server体系： Ubuntu22.04
Kubernetes环境: v1.29.7

2.2 部署NFS Server

安装nfs-server

apt install -y nfs-kernel-server nfs-common

复制代码

设置nfs, 把数据目次挂着到ssd磁盘

sudo mkdir -p /ssd/data
sudo chown nobody:nogroup /ssd/data
sudo chmod 777 /ssd/data

复制代码

编辑/etc/exports文件

/ssd/data *(rw,sync)

复制代码

❔ 参数说明：

/ssd/data：指定服务器上的共享目次路径。
*：表示允许全部的客户端访问该共享。如果是业务环境要求访问限制，可以替换为特定的IP地点或子网，例如 Kubernetes集群的网段。
rw ：read-write，表示客户端具有读写该共享目次的权限。如果设置为 ro（read-only），则客户端只能读取数据，无法写入。
sync（同步写入）：表示全部对该共享目次的写入操作都将同步地写入到磁盘上。客户端发起的写操作必须等到数据写入磁盘后才会被确认。如果设置为 async，则写入操作会在数据实际写入磁盘之前就返回，这样会提高性能，但在体系瓦解时大概导致数据丢失。

重启nfs服务

systemctl enable nfs-server
systemctl restart nfs-server

复制代码

查看nfs设置

exportfs -rv

复制代码

输出如下：

exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check' specified for export "*:/ssd/data".
Assuming default behaviour ('no_subtree_check').
NOTE: this default has changed since nfs-utils version 1.0.x
exporting *:/ssd/data

复制代码

证明设置成功

2.3 Master节点挂载测试

查看共享目次

showmount -e 192.168.3.20

复制代码

输出如下：

Export list for 192.168.3.20:
/ssd/data *

复制代码

创建共享目次 /mnt/share

mkdir /mnt/share

复制代码

挂载nfs目次

mount -t nfs 192.168.3.200:/ssd/data /mnt/share

复制代码

创建测试文件

echo “test” > /mnt/share/test.txt

复制代码

创建成功，证明写入成功

卸载nfs共享目次

umount /mnt/share

复制代码

2.4 创建 PV和PVC

接下来我们基于 NFS存储创建PV和PVC，验证不同的策略：
第一个PV和PVC：

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-rwo
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
nfs:
path: /ssd/data
server: 192.168.3.20
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-rwo
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi

复制代码

第二个PV和PVC：

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-rwx
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
nfs:
path: /ssd/data
server: 192.168.3.20
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-rwx
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi

复制代码

第三个PV和PVC：

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-rox
spec:
capacity:
storage: 1Gi
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Retain
nfs:
path: /ssd/data
server: 192.168.3.20
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-rox
spec:
accessModes:
- ReadOnlyMany
resources:
requests:
storage: 1Gi

复制代码

❔ 参数说明：

PV和PVC的volumeMode保持划一：
- Filesystem 模式：
  - 当 volumeMode 设置为 Filesystem （默认值）时，存储卷会被挂载到Pod的一个目次中。如果存储卷是基于块装备且装备为空，Kubernetes 会在第一次挂载前主动在装备上创建一个文件体系。
  - 这种模式适合大多数应用场景，用户可以像使用普通文件体系一样访问存储卷。
- Block 模式：
  - 当 volumeMode 设置为 Block 时，存储卷会作为一个原始块装备提供给Pod，而不经过文件体系层。这意味着该卷在Pod中被暴露为一个块装备。
  - 这种模式适合需要直接访问块存储的应用，如数据库或需要最高I/O性能的应用，但应用步伐必须可以或许处理原始块装备的数据管理。
PV和PVC的accessModes保持划一:

访问模式缩写描述典范使用场景ReadWriteOnceRWO该存储卷可以被一个节点上的Pod以读写方式挂载。当 Pod 在同一节点上运行时，ReadWriteOnce 访问模式仍旧可以允许多个 Pod 访问该卷。适用于单实例应用，如数据库（MySQL、PostgreSQL）。ReadOnlyManyROX该存储卷可以被多个节点上的多个Pod以只读方式挂载。适用于需要共享静态内容的场景，如设置文件或日志查看。ReadWriteManyRWX该存储卷可以被多个节点上的多个Pod以读写方式挂载。适用于需要多节点并发读写的场景，如共享文件存储。ReadWriteOncePodRWOP该存储卷只能被一个Pod以读写方式挂载，即使在同一节点上也不能被其他Pod挂载。 1.22+ 版本后支持。用于增强Pod间的独占资源访问，防止多个Pod竞争使用。

PV的ReclaimPolicy

接纳策略描述适用场景Retain保留数据，即使PVC被删除，PV中的数据仍会被保留，需要手动清理或重新绑定PVC。适用于需要数据持久保留的场景，如数据库或备份存储。Delete删除PV和存储资源。当PVC被删除时，Kubernetes会主动删除PV及其对应的存储资源。适用于临时数据或不需要保留的数据，如测试环境。Recycle （已废弃）清空数据并将PV重置为Available状态，以便被新的PVC绑定。此功能在Kubernetes 1.11之后已废弃。已不推荐使用，Kubernetes 1.11版本之前的旧集群大概仍支持。

创建三个PV和PVC

kubectl apply -f pv-rwo.yaml
kubectl apply -f pv-rwm.yaml
kubectl apply -f pv-rom.yaml

复制代码

2.5 观察PV和PVC的状态

查看PV状态

kubectl get pv

复制代码

输出如下：

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
pv-rox 1Gi ROX Retain Available <unset> 11s
pv-rwo 1Gi RWO Delete Available <unset> 106s
pv-rwx 1Gi RWX Retain Available <unset> 42s

复制代码

查看PVC状态

kubectl get pv
c

复制代码

输出如下：

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
pvc-rox Bound pvc-e32cf856-b00b-4012-a25a-74c82ba8f092 1Gi ROX nfs-class <unset> 2m9s
pvc-rwo Bound pvc-c864776b-5811-452f-9e98-f50466922be2 1Gi RWO nfs-class <unset> 3m44s
pvc-rwx Bound pvc-7bebb579-5f8a-4994-a7a8-02bde0d651c2 1Gi RWX nfs-class <unset> 2m41s

复制代码

❔ 说明：PV和PVC的生命周期

PV的生命周期状态表：

生命周期阶段状态描述AvailablePV已创建且未绑定到任何PVC，表示可供PVC使用。BoundPV已绑定到一个PVC，表示正在被使用。ReleasedPVC被删除后，PV进入Released状态，表示PV已经释放，但资源尚未被重新使用，数据仍大概存在。FailedPV无法绑定到PVC，或接纳过程中出现错误。通常需要管理员手动干预修复。Reclaim根据persistentVolumeReclaimPolicy设置，PV的接纳策略可以是Retain、Recycle或Delete。

PVC的生命周期：

生命周期阶段状态描述PendingPVC已创建，但尚未找到合适的PV进行绑定。BoundPVC已成功绑定到一个PV，存储资源可以被Pod使用。LostPV被删除或失效，PVC进入Lost状态，表示无法继续访问存储资源。通常需要管理员处理。 2.6 Pod挂载不同PVC测试

2.6.1 创建Pod并挂载ReadWriteOnce的PV

将PVC pvc-rwo挂载到nginx1：

apiVersion: v1
kind: Pod
metadata:
name: nginx1
spec:
containers:
- name: nginx1
image: harbor.zx/hcie/nginx:1.27.1
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: my-config
volumes:
- name: my-configvim
persistentVolumeClaim:
claimName: pvc-rwo

复制代码

创建pod

kubectl apply -f nginx1.yaml

复制代码

尝试再创建一个Pod nginx2，使用同一个PVC，观察PVC挂载环境。

apiVersion: v1
kind: Pod
metadata:
name: nginx2
spec:
containers:
- name: nginx2
image: harbor.zx/hcie/nginx:1.27.1
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: my-config
volumes:
- name: my-config
persistentVolumeClaim:
claimName: pvc-rwo

复制代码

查看pod的状态

kubectl get pod
-owide

复制代码

输出如下：

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx1 1/1 Running 0 66m 172.16.135.207 k8s-master3 <none> <none>
nginx2 1/1 Running 0 61m 172.16.126.55 k8s-worker2 <none> <none>

复制代码

❓ 思考：测试发现，无论nginx1与nginx2运行在同一工作节点或不同工作节点上都能正常读写。

这里推测，虽然Kubernetes的ReadWriteOnce模式限制了跨节点的读写访问，但某些存储体系（如NFS）本身是支持多节点并发访问的。因此即使Kubernetes中的访问模式设置为ReadWriteOnce，NFS协议也不强制执行这种访问限制。

2.6.2 创建Pod并挂载ReadWriteOncePod的PV

现在将nginx1、nginx2删除：

kubectl delete -f nginx1.yaml
kubectl delete -f nginx2.yaml
kubectl delete -f pv-rwo.yaml

复制代码

将第一个PV和PVC的策略改为ReadWriteOncePod

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-rwo
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOncePod
persistentVolumeReclaimPolicy: Retain
nfs:
path: /ssd/data
server: 192.168.3.20
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-rwo
spec:
accessModes:
- ReadWriteOncePod
resources:
requests:
storage: 1Gi

复制代码

创建pv和pvc

kubectl apply -f pv-rwo.yaml

复制代码

创建nginx1和nginx2

kubectl apply -f nginx1.yaml
kubectl apply -f nginx2.yaml

复制代码

查看pod

kubectl get pod

复制代码

输出如下：

NAME READY STATUS RESTARTS AGE
nginx1 1/1 Running 0 67s
nginx2 0/1 Pending 0 66s

复制代码

这时nginx2状态是“Pending”出现无法挂载的环境。

nginx2详细信息如下：

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 12s default-scheduler 0/5 nodes are available: 1 node has pod using PersistentVolumeClaim with the same name and ReadWriteOncePod access mode, 4 node(s) didn't match Pod's node affinity/selector. preemption: 0/5 nodes are available: 1 No preemption victims found for incoming pod, 4 Preemption is not helpful for scheduling.

复制代码

可以看到nginx2无法挂载是因为 ReadWriteOncePod 只允许一个Pod挂载。
为了做好存储访问控制，可以思量使用其他存储插件或者存储体系。
另外，可以使用ReadWriteOncePod（RWOP）访问模式来替代ReadWriteOnce，该模式在Kubernetes 1.22及更高版本中可用，可以或许限制PV只能被一个Pod挂载，即使在同一节点上也不允许其他Pod使用。

2.6.3 创建Pod并挂载ReadWriteMany的PV

现在将nginx1、nginx2删除：

kubectl delete -f nginx1.yaml
kubectl delete -f nginx2.yaml

复制代码

修改成pv-rwx的pvc

volumes:
- name: my-config
persistentVolumeClaim:
claimName: pvc-rwx

复制代码

重新创建nginx1、nginx2

kubectl apply -f nginx1.yaml
kubectl apply -f nginx2.yaml

复制代码

nginx1测试读写

[root@k8s-master1 ~]# kubectl exec -it nginx1 -- bash
root@nginx1:/# echo "nginx1" >>/usr/share/nginx/html/nginx1
root@nginx1:/# cat /usr/share/nginx/html/nginx1
nginx1

复制代码

nginx2测试读写

[root@k8s-master1 ~]# kubectl exec -it nginx2 -- bash
root@nginx2:/# echo "nginx2" >>/usr/share/nginx/html/nginx2
root@nginx2:/# cat /usr/share/nginx/html/nginx2
nginx2

复制代码

证明一个pv可以共享挂载给多个Pod。

2.6.4 创建Pod并挂载ReadOnlyMany的PV

现在将nginx1、nginx2删除：

kubectl delete -f nginx1.yaml
kubectl delete -f nginx2.yaml

复制代码

Pod修改成pv-rox的pvc

containers:
- name: nginx1
image: harbor.zx/hcie/nginx:1.27.1
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: my-config
readOnly: true
volumes:
- name: my-config
persistentVolumeClaim:
claimName: pvc-rox

复制代码

重新创建nginx1、nginx2

kubectl apply -f nginx1.yaml
kubectl apply -f nginx2.yaml

复制代码

查看nginx1详细信息，执行以下下令：

kubectl describe pod nginx1

复制代码

输出如下：

Containers:
nginx1:
Container ID: containerd://28659839ee65b3be6579dd5d519ebcd89fefbf05e9908feb21b504728c19527a
Image: harbor.zx/hcie/nginx:1.27.1
Image ID: harbor.zx/hcie/nginx@sha256:127262f8c4c716652d0e7863bba3b8c45bc9214a57d13786c854272102f7c945
Port: <none>
Host Port: <none>
State: Running
Started: Thu, 17 Oct 2024 10:16:53 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/usr/share/nginx/html from my-config (ro)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vcmlw (ro)

复制代码

存储卷是以只读访问方式挂载。

nginx1测试写

[root@k8s-master1 ~]# kubectl exec -it nginx1 -- bash
root@nginx1:/# echo "nginx1" >>/usr/share/nginx/html/nginx1

复制代码

输出如下：

bash: /usr/share/nginx/html/nginx1: Read-only file system

复制代码

证明该存储卷是只读。

nginx2测试读

[root@k8s-master1 ~]# kubectl exec -it nginx2 -- bash
root@nginx2:/# cat /usr/share/nginx/html/nginx2
nginx2
root@nginx2:/# cat /usr/share/nginx/html/nginx1
nginx1

复制代码

证明一个pv可以“只读”方式共享给多个Pod

2.7 PV的接纳策略测试

❔ 说明：因为Recycle策略已经被丢弃了，所以只验证Retain和Delete两种策略类型。
登录nfs-server，创建卷目次

mkdir /ssd/data/{retain,delete}

复制代码

编写Retain卷文件

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-retain
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
nfs:
path: /ssd/data/retain
server: 192.168.3.20
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-retain
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: ""

复制代码

编写Delete卷文件

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-delete
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
nfs:
path: /ssd/data/delete
server: 192.168.3.20
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-delete
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
storageClassName: ""

复制代码

创建存储卷

kubectl apply -f pv-retain.yaml
kubectl apply -f pv-delete.yaml

复制代码

创建pod测试

apiVersion: v1
kind: Pod
metadata:
name: pod-retain
spec:
containers:
- name: busybox
image: harbor.zx/library/busybox:1.29-2
command: ["sh", "-c", "echo 'Hello from Retain' > /mnt/data/test.txt; sleep 3600"]
volumeMounts:
- mountPath: /mnt/data
name: volume
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc-retain
---
apiVersion: v1
kind: Pod
metadata:
name: pod-delete
spec:
containers:
- name: busybox
image: harbor.zx/library/busybox:1.29-2
command: ["sh", "-c", "echo 'Hello from Delete' > /mnt/data/test.txt; sleep 3600"]
volumeMounts:
- mountPath: /mnt/data
name: volume
volumes:
- name: volume
persistentVolumeClaim:
claimName: pvc-delete

复制代码

执行以下下令创建两个Pod：

kubectl apply -f pv-test.yaml

复制代码

删除pod、pvc-retain和pvc-delete，观察PV的状态变化。

kubectl delete pod pod-retain
kubectl delete pod pod-delete
kubectl delete pvc pvc-retain
kubectl delete pvc pvc-delete

复制代码

观察pv的接纳状态，执行以下下令：

kubectl get pv
-w

复制代码

输出如下：

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
3m33s
pv-retain 1Gi RWO Retain Bound default/pvc-reta in <unset> 3m34s
...
pv-retain 1Gi RWO Retain Released default/pvc-reta in <unset>
---
pv-delete 1Gi RWO Delete Bound default/pvc-dele te <unset> 4m42s
...
pv-delete 1Gi RWO Delete Released default/pvc-dele te <unset> 4m41s
pv-delete 1Gi RWO Delete Failed default/pvc-dele te <unset> 4m41s

复制代码

pv状态从Bound到Released，但是Delete策略接纳nfs的存储卷失败。

查看nfs底层数据

root@ub22:/ssd/data# ls -l delete/
total 4
-rw-r--r-- 1 nobody nogroup 18 10月 17 11:27 test.txt
root@ub22:/ssd/data# ls -l retain/
total 4
-rw-r--r-- 1 nobody nogroup 18 10月 17 11:27 test.txt

复制代码

底层的数据没有被删除。

2.7.1 手动删除并接纳卷

查看pv-delete详细信息

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning VolumeFailedDelete 6m2s persistentvolume-controller error getting deleter volume plugin for volume "pv-delete": no deletable volume plugin matched

复制代码

因为我并没有使用nfs的provider进行管理导致，所以不支持nfs存储卷删除操作。

登录NFS服务器，手动删除PV对应的目次。例如：

# 登录到NFS服务器，手动删除目录
rm -rf /ssd/data/delete

复制代码

然后删除PV资源：

kubectl delete pv pv-delete

复制代码

或者，使用Finalizer强制删除PV

如果PV已经标记为Failed，可以尝试移除PV的finalizer以强制删除：
1. kubectl patch pv pv-delete -p '{"metadata":{"finalizers":null}}'
复制代码

3 总结

Kubernetes 通过PV和PVC的方式提供了后端存储同一管理和机动存储的办理方案，在实际生产环境中，您可以根据业务需求选择合适的存储类型，并订定美满的数据备份方案，是确保体系稳定运行的关键。

4 参考文献

Kubernetes 官方文档
NFS 存储设置

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)