首页 > 网站技巧 > 服务器 > 云和虚拟化 > 云其它 > K8S的PV和PVC详解

一篇文章读懂K8S的PV和PVC以及实践攻略

2024-10-22 09:59:05 作者：StevenZeng学堂

本文详细介绍了Kubernetes中的存储卷（Volume）机制,包括PersistentVolume（PV）、PersistentVolumeClaim（PVC）及其与后端存储的关系,文中通过代码介绍的非常详细,需要的朋友可以参考下

1 概念

1.1 什么是存储卷？

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

1.2 存储卷的类型与使用场景

存储类型	描述	适用场景
`emptyDir`	Pod 生命周期内的临时存储	适合临时数据存储，如缓存、临时文件等。
`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保持一致:

访问模式	缩写	描述	典型使用场景
ReadWriteOnce	RWO	该存储卷可以被一个节点上的Pod以读写方式挂载。当 Pod 在同一节点上运行时，ReadWriteOnce 访问模式仍然可以允许多个 Pod 访问该卷。	适用于单实例应用，如数据库（MySQL、PostgreSQL）。
ReadOnlyMany	ROX	该存储卷可以被多个节点上的多个Pod以只读方式挂载。	适用于需要共享静态内容的场景，如配置文件或日志查看。
ReadWriteMany	RWX	该存储卷可以被多个节点上的多个Pod以读写方式挂载。	适用于需要多节点并发读写的场景，如共享文件存储。
ReadWriteOncePod	RWOP	该存储卷只能被一个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 pvc

输出如下：

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的生命周期状态表：

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

PVC的生命周期：

生命周期阶段	状态描述
`Pending`	PVC已创建，但尚未找到合适的PV进行绑定。
`Bound`	PVC已成功绑定到一个PV，存储资源可以被Pod使用。
`Lost`	PV被删除或失效，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以强制删除：
```
kubectl patch pv pv-delete -p '{"metadata":{"finalizers":null}}'
```

3 总结

Kubernetes 通过PV和PVC的方式提供了后端存储统一管理和灵活存储的解决方案，在实际生产环境中，您可以根据业务需求选择合适的存储类型，并制定完善的数据备份方案，是确保系统稳定运行的关键。

4 参考文献

到此这篇关于K8S的PV和PVC以及实践攻略的文章就介绍到这了,更多相关K8S的PV和PVC详解内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

一篇文章读懂K8S的PV和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 参考文献

您可能感兴趣的文章: