当前位置：首页 > news >正文

配置和使用持久卷

news 来源：原创 2025/5/5 6:07:30

配置和使用持久卷

文章目录

配置和使用持久卷
@[toc]
一、PV与PVC的持久化存储机制
二、PV和PVC的生命周期
三、创建基于NFS的PV
1.准备NFS共享目录
2.创建PV

四、基于PVC使用PV
1.创建PVC
2.使用PVC

五、基于StorageClass实现动态卷制备
1.获取NFS服务器的连接信息
2.获取nfs-subdir-external-provisioner源码包
3.创建ServiceAccount
4.部署nfs-subdir-external-provisioner组件
5.创建基于NFS共享存储的StorageClass
6.创建用于测试的PVC
7.创建Pod测试PV的使用

一、PV与PVC的持久化存储机制

Kubernetes 中的 PV（PersistentVolume） 和 PVC（PersistentVolumeClaim） 是持久化存储的核心机制，旨在解耦存储资源的管理与使用，

核心概念与职责分离

PV（持久卷）
由管理员创建和维护，代表集群中的实际存储资源（如 NFS、云存储等），定义存储容量、访问模式、回收策略等属性。PV 的生命周期独立于 Pod，即使 Pod 被删除，数据仍可保留。
PVC（持久卷声明）
由用户创建，声明存储需求（如容量、访问模式），Kubernetes 会根据 PVC 的请求自动绑定符合条件的 PV。PVC 屏蔽了底层存储细节，用户无需关心具体存储类型。

生命周期与绑定机制

资源供应
- 静态供应：管理员预先创建 PV，用户通过 PVC 申请。
- 动态供应：通过 StorageClass 动态创建 PV。用户只需指定 StorageClass 模板，系统按需生成 PV 并与 PVC 绑定。
绑定规则
- PVC 需与 PV 的 访问模式（如 ReadWriteOnce、ReadOnlyMany）、存储容量 和 StorageClass 匹配。
- 绑定后，PV 被独占使用，无法与其他 PVC 绑定。

关键配置参数

PV 配置
- 访问模式：定义存储的挂载权限（如单节点读写、多节点只读）。
- 回收策略
  - Retain：保留数据，需手动清理；
  - Delete：自动删除存储资源；
  - Recycle（已废弃）：数据擦除后重新可用。
- StorageClass：用于动态供应时分类存储特性（如性能等级）。
PVC 配置
- 需声明 存储容量、访问模式，并可通过标签筛选特定 PV。

使用场景与优势

数据持久化：适用于数据库、日志存储等需保留数据的场景。
共享存储：多个 Pod 通过 PVC 共享同一 PV（需支持多节点访问模式，如 NFS）。
解耦管理：存储管理员负责 PV 运维，开发者通过 PVC 按需申请资源。

回收与维护

PVC 删除后
- 若 PV 回收策略为 Retain，需手动清理数据并删除 PV；
- 若为 Delete，则自动释放存储资源。

PV 和 PVC 通过抽象存储资源的管理与使用，实现了存储的灵活分配和持久化。静态供应适合固定存储需求，动态供应则通过 StorageClass 实现自动化，两者结合为有状态应用提供了高效的存储解决方案。

二、PV和PVC的生命周期

在 Kubernetes 中，PV（PersistentVolume） 和 PVC（PersistentVolumeClaim） 的生命周期通过资源供应、绑定、使用、释放与回收等阶段实现存储资源的管理，以下是其核心要点：

一、PV 生命周期

供应阶段（Provisioning）
- 静态供应：管理员手动创建 PV，定义存储容量、访问模式（如 ReadWriteOnce）和回收策略（Retain/Delete/Recycle）。此时 PV 状态为 Available（可用），等待 PVC 绑定。
- 动态供应：通过 StorageClass 自动创建 PV。当用户声明 PVC 时，系统根据 StorageClass 模板动态生成 PV 并绑定。
绑定阶段（Binding）
- PVC 请求存储资源时，Kubernetes 匹配符合要求的 PV（容量、访问模式等）。绑定后 PV 状态变为 Bound（已绑定），且被该 PVC 独占使用。
使用阶段（Using）
- Pod 通过挂载 PVC 使用 PV 的存储资源。多个 Pod 可共享同一 PVC（需支持多节点访问模式）。
释放与回收阶段（Releasing & Recycling）
- Released（已释放）：删除 PVC 后，PV 进入此状态，数据保留但不可被新 PVC 绑定。具体行为由回收策略决定：
  - Retain（默认）：需管理员手动清理数据并删除 PV。
  - Delete：自动删除底层存储资源（如云盘），PV 被销毁。
  - Recycle（已废弃）：数据擦除后重新变为 Available，现已被动态供应取代。
- Failed（失败）：PV 操作异常（如存储后端故障）时进入此状态，需管理员介入修复。

二、PVC 生命周期

创建与绑定
- 用户定义 PVC 的存储需求（容量、访问模式），系统匹配或动态生成 PV。若未找到合适 PV，PVC 保持 Pending（等待）状态。
使用阶段
- 绑定成功后，PVC 状态为 Bound，Pod 通过挂载 PVC 使用存储资源。
删除与释放
- 删除 PVC 后，其绑定的 PV 根据回收策略进入 Released 或删除状态。若 PV 为动态供应且策略为 Delete，则 PV 和存储资源一并销毁。

三、关键状态与策略对比

状态/策略	描述
PV 状态：Available	空闲待绑定，支持手动或动态分配
PV 状态：Bound	已与 PVC 绑定，存储资源被占用
PV 状态：Released	PVC 删除后保留数据，需按策略处理
回收策略：Retain	数据保留，需手动清理（适用于敏感数据场景）
回收策略：Delete	自动销毁存储资源（适用于临时环境或云存储）

四、生产实践建议

优先使用动态供应：通过 StorageClass 自动化 PV 创建，避免资源浪费。
合理设置回收策略：生产环境推荐 Retain 策略防止误删数据，测试环境可用 Delete 策略。
监控 PV 状态：定期检查 Released 或 Failed 状态的 PV，防止资源泄漏或故障积累。

通过上述机制，PV 和 PVC 实现了存储资源的解耦与高效管理，为有状态应用提供可靠的持久化支持。

三、创建基于NFS的PV

前面已经学习过了NFS卷的挂载，NFS卷是一种集群共享存储的简单解决方案。

1.准备NFS共享目录

创建两个NFS共享目录来为两个PV提供存储资源

（1）创建要共享的物理目录

[root@master ~]# mkdir -p /test-storage/nfs1 /test-storage/nfs2

（2）修改/etc/exports配置文件，添加以下两行定义，增加两个共享目录

[root@master ~]# vim /etc/exports
[root@master ~]# cat /etc/exports
/test-storage/nfs 192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)
/test-storage/nfs1 192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)
/test-storage/nfs2 192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)

（3）执行生效配置

[root@master ~]# exportfs -av
exporting 192.168.10.0/24:/test-storage/nfs2
exporting 192.168.10.0/24:/test-storage/nfs1
exporting 192.168.10.0/24:/test-storage/nfs
[root@master ~]#

2.创建PV

（1）编写PV配置文件

[root@master ~]# cat nfs-pv.yaml 
apiVersion: v1
kind: PersistentVolume
metadata:name: nfs-pv1
spec:capacity:storage: 5Gi                       # 定义PV的大小volumeMode: Filesystem             # 卷模式accessModes:- ReadWriteMany                      # 访问模式persistentVolumeReclaimPolicy: Recycle   # 回收策略nfs:                                 # 存储类型path: /test-storage/nfs1server: 192.168.10.30---apiVersion: v1
kind: PersistentVolume
metadata:name: nfs-pv2
spec:capacity:storage: 3Gi                       # 定义PV的大小volumeMode: Filesystem             # 卷模式accessModes:- ReadWriteOnce                      # 访问模式persistentVolumeReclaimPolicy: Recycle   # 回收策略nfs:                                 # 存储类型path: /test-storage/nfs2server: 192.168.10.30[root@master ~]#

这是一个多文档的YAML配置文件，包括两个PV的定义，为了示范，这里将两个PV的访问模式和容量设置得不一样

（2）基于该配置文件创建PV

[root@master ~]# kubectl create -f nfs-pv.yaml 
persistentvolume/nfs-pv1 created
persistentvolume/nfs-pv2 created
[root@master ~]#

（3）查看所创建的PV

[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
nfs-pv1   5Gi        RWX            Recycle          Available                                   12s
nfs-pv2   3Gi        RWO            Recycle          Available                                   12s
[root@master ~]#

其中RECLAIM POLICY列表示PV的回收策略，STATUS列表示状态，值为Available说明PV处于可用状态。

本列产生了两个PV，说明PV就是将实际的存储资源或设备抽象成了Kubernetes的资源。实际应用中，PV通常是由运维人员进行运维的，开发人员一般运维PVC，并部署和管理Pod。

四、基于PVC使用PV

前面创建了PV，PV需要通过PVC声明才能为Pod所用。PVC消耗的是PV资源。通过PVC使用存储资源时无须关心底层的存储实现细节。

1.创建PVC

（1）编写PVC配置文件

[root@master ~]# cat nfs-pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: nfs-pvc1
spec:accessModes:- ReadWriteMany                    # 访问模式volumeMode: Filesystem              # 卷模式resources:requests:storage: 4Gi                      # 声明存储的大小
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: nfs-pvc2
spec:accessModes:- ReadWriteOnce                    # 访问模式volumeMode: Filesystem              # 卷模式resources:requests:storage: 3Gi                      # 声明存储的大小

（2）基于该配置文件创建PVC

[root@master ~]# kubectl create -f nfs-pvc.yaml 
persistentvolumeclaim/nfs-pvc1 created
persistentvolumeclaim/nfs-pvc2 created

（3）查看所创建的PVC

[root@master ~]# kubectl get pvc
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc1   Bound    nfs-pv1   5Gi        RWX                           29s
nfs-pvc2   Bound    nfs-pv2   3Gi        RWO                           29s

PVC会通过定义的访问模式、存储大小去匹配满足条件的PV。其中，名称为nfs-pvc1的PVC请求的是4Gi容量，Kubernetes自动匹配容量为5Gi的PV。这里可以发现STATUS列的值为Bound，表示PVC已经绑定了PV，VOLUME列表示所绑定的PV。

（4）查看之前的PV

[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM              STORAGECLASS   REASON   AGE
nfs-pv1   5Gi        RWX            Recycle          Bound    default/nfs-pvc1                           9m53s
nfs-pv2   3Gi        RWO            Recycle          Bound    default/nfs-pvc2                           9m53s

可以发现，PV的状态也变成了Bound，CLAIM列表示的是与PV绑定的PVC，其中的default是名称空间的名称。因为PV是集群级的全局资源，并不属于任何名称空间，而PVC是属于特定名称空间资源，PV可以与任何名称空间的PVC绑定。

2.使用PVC

Pod将PVC作为卷使用，并通过卷访问存储资源。PVC必须使用它的Pod位于同一名称空间。Kubernetes在Pod的名称空间中查找指定名称的PVC，并使用它来获得希望使用的PV。之后，卷会被挂载到Pod中。

（1）编写Pod配置文件，可以在之前文件基础上修改

[root@master ~]# cat pvc-pod.yaml 
apiVersion: v1
kind: Pod
metadata:name: pvc-demo
spec:containers:- name: busyboximage: busyboxvolumeMounts:                # 容器挂载卷- name: pod-volume          # 要挂载的卷名称mountPath: /pod-data      # 挂载到容器的路径# 容器启动命令及参数command: ["/bin/sh"] args: ["-c","while true;do /bin/echo  $(date +%T) '记录' >> /pod-data/test.txt;sleep 60; done;"] volumes:                    # 在Pod级别定义卷- name: pod-volume        # 卷名称persistentVolumeClaim:claimName: nfs-pvc1        # PVC名称readOnly: false            # 不使用只读模式

（2）基于配置文件创建Pod

[root@master ~]# kubectl create -f pvc-pod.yaml 
pod/pvc-demo created
[root@master ~]#

（3）进入该Pod容器的Shell环境，查看由容器命令写入的test.txt文件，可以看到该文件中记录的内容

[root@master ~]# kubectl get pod
NAME       READY   STATUS    RESTARTS   AGE
pvc-demo   1/1     Running   0          54s
[root@master ~]# kubectl exec -it pvc-demo -- /bin/sh
/ # cat /pod-data/test.txt 
05:59:19 记录
06:00:19 记录
/ # exit

（4）删除该Pod

[root@master ~]# kubectl delete po pvc-demo
pod "pvc-demo" deleted

（5）观察PVC，可以发现所用的PVC没有发生变化

[root@master ~]# kubectl get pvc
NAME       STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nfs-pvc1   Bound    nfs-pv1   5Gi        RWX                           11m
nfs-pvc2   Bound    nfs-pv2   3Gi        RWO                           11m

（6）删除所创建的PVC

[root@master ~]# kubectl delete -f nfs-pvc.yaml 
persistentvolumeclaim "nfs-pvc1" deleted
persistentvolumeclaim "nfs-pvc2" deleted

（7）观察PV，可以发现PV处于Released状态

[root@master ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM              STORAGECLASS   REASON   AGE
nfs-pv1   5Gi        RWX            Recycle          Released   default/nfs-pvc1                           19m
nfs-pv2   3Gi        RWO            Recycle          Released   default/nfs-pvc2                           19m

（8）删除所创建的PV

[root@master ~]# kubectl delete -f nfs-pv.yaml 
persistentvolume "nfs-pv1" deleted
persistentvolume "nfs-pv2" deleted

（9）查看PV对应的NFS共享目录，发现由Pod容器写入的test.txt文件仍然被保存着

[root@master ~]# cat /test-storage/nfs1/test.txt 
05:59:19 记录
06:00:19 记录
06:01:19 记录

五、基于StorageClass实现动态卷制备

利用StorageClass实现动态卷制备，需要相应的卷插件和外部存储系统支持。为便于实验操作，这里选择前面已经部署的NFS共享目录作为外部存储资源，利用NFS的外部存储基于StorageClass实现动态卷制备。Kubernetes内置的制备器不包括NFS，也就不包含内部NFS驱动，管理员需要使用外部驱动为NFS创建StorageClass。目前常用的第三开源的NFS制备器（卷插件）由nfs-subdir-external-provisioner和nfs-ganesha-server-and-external-provisioner这两种，这里选择第一种，它基于现有的NFS服务器通过PVC请求来支持PV的动态分配，自动创建的PV被命名为 ${namespace}-$ {pvcName}-${pvName}，由名称空间、PVC和PV这3个资源的名称组合而成。目前在Kubernetes集群种部署nfs-subdir-external-provisioner组件的方式有3种，分别是Helm、Kustomize和Manually（手动）。下面示范手动部署方式，并测试其动态卷制备功能。

1.获取NFS服务器的连接信息

如果没有NFS服务器，则需要先部署NFS服务器。

确保可以从Kubernetes集群访问NFS服务器，并获取连接到该服务器所需的信息，至少需要获取它的主机名

这里利用之前创建的NFS服务器和发布的共享目录。

IP地址：192.168.10.30

共享目录：/test-storage/nfs

2.获取nfs-subdir-external-provisioner源码包

从源码托管平台搜索nfs-subdir-external-provisioner，找到后下载相应的源码包，本例下载的是（nfs-subdir-external-provisioner-4.0.18.tar.gz），重点是要使用其deploy目录种的所有文件。直接将整个deploy目录拷贝到控制平面节点主机上。

[root@master ~]# ls deploy/class.yaml  'deployment(复件).yaml'   deployment.yaml   kustomization.yaml   objects   rbac.yaml   test-claim.yaml   test-pod.yaml

3.创建ServiceAccount

本例所在的Kubernetes集群基于RBAC进行权限控制，因此需要创建一个拥有一定权限的ServiceAccount，以便绑定要部署的nfs-subdir-external-provisioner组件。如果要部署的项目所在的名称空间不是默认的default，需要将deploy/rbac.yaml文件种namespace字段值修改为要部署项目的名称空间。这里保持默认值，执行以下命令创建ServiceAccount等RBAC对象。

[root@master ~]# kubectl create -f deploy/rbac.yaml 
serviceaccount/nfs-client-provisioner created
clusterrole.rbac.authorization.k8s.io/nfs-client-provisioner-runner created
clusterrolebinding.rbac.authorization.k8s.io/run-nfs-client-provisioner created
role.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created
rolebinding.rbac.authorization.k8s.io/leader-locking-nfs-client-provisioner created

4.部署nfs-subdir-external-provisioner组件

以Deployment的形式部署并运行nfs-subdir-external-provisioner组件，该组件提供NFS制备器，基于NFS共享目录创建挂载点，运行nfs-client-provisioner程序，以便自动创建PV，并将PV与NFS挂载点关联起来。

根据本例环境修改deploy/deployment.yaml，设置实际的NFS服务器连接信息

[root@master ~]# cat deploy/deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisionerlabels:app: nfs-client-provisionernamespace: default               # 可以根据项目需要替换名称空间
spec:replicas: 1strategy:type: Recreate                 #  设置升级策略为删除再创建(默认为滚动更新)selector:matchLabels:app: nfs-client-provisionertemplate:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client-provisionercontainers:- name: nfs-client-provisioner# 针对国内网络环境修改其中镜像仓库的地址# image: registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2image: registry.cn-hangzhou.aliyuncs.com/weiyigeek/nfs-subdir-external-provisioner:v4.0.2volumeMounts:                     # 卷挂载点- name: nfs-client-rootmountPath: /persistentvolumesenv:# 制备器名称和值，以后创建的StorageClass的provisioner字段要用到它- name: PROVISIONER_NAME value: k8s-sigs.io/nfs-subdir-external-provisioner- name: NFS_SERVER value: 192.168.10.30    # NFS服务器设置，需与卷定义的配置保持一致- name: NFS_PATH value: /test-storage/nfs   # NFS共享目录，需与卷定义的配置保持一致volumes:                               # 卷定义- name: nfs-client-rootnfs:server: 192.168.10.30         # NFS服务器设置path: /test-storage/nfs       # NFS共享目录

执行部署

[root@master ~]# kubectl apply -f deploy/deployment.yaml 
deployment.apps/nfs-client-provisioner created

查看运行该Pod的组件，发现本例中该Pod已被部署到node1节点上

[root@master ~]# kubectl get pod -o wide
NAME                                      READY   STATUS                   RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
nfs-client-provisioner-548bdbd66c-jst69   1/1     Running                  0          81s     10.244.166.143   node1   <none>           <none>

5.创建基于NFS共享存储的StorageClass

要实现动态制备，必须创建StorageClass。编写配置文件

[root@master ~]# cat nfs-storageclass.yaml 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:name: nfs-storage               # StorageClass对象名称，供PVC引用annotations:#   设置为默认的storageclassstorageclass.kubernetes.io/is-default-class: "true"
# 卷制备器名称，必须和nfs-subdir-external-provisioner组件的PROVISIONER_NAME的值一致
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner 
parameters:archiveOnDelete: "true"    # 设置为"false"时删除PVC不会保留数据,"true"则保留数据

执行创建

[root@master ~]# kubectl apply -f nfs-storageclass.yaml 
storageclass.storage.k8s.io/nfs-storage created

查看所创建的StorageClass，可以发现这是一个默认的StorageClass

[root@master ~]# kubectl get sc
NAME                    PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
nfs-storage (default)   k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate           false                  9s

6.创建用于测试的PVC

接下来创建一个PVC测试NFS制备器自动创建PV，并于该PV绑定

[root@master ~]# cat test-sc-pvc.yaml 
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: test-sc-pvc
spec:storageClassName: nfs-storage    # 需要与前面创建的StorageClass名称一致accessModes:- ReadWriteOnceresources:requests:storage: 1Mi

其中关键是要通过storageClassName字段指定要选用的StorageClass名称。

基于配置文件创建PVC

[root@master ~]# kubectl apply -f test-sc-pvc.yaml 
persistentvolumeclaim/test-sc-pvc created

查看PVC信息，由于该StorageClass的卷绑定模式为Immediate，即立即绑定，因此PVC创建之后就调用与该StorageClass关联的制备器来动态创建并绑定PV

[root@master ~]# kubectl get pvc
NAME          STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-sc-pvc   Bound    pvc-d197f44a-1588-47c5-aff9-5bcd85d76443   1Mi        RWO            nfs-storage    5s

PV卷名是自动生成的随机字符串，只要不删除PVC，与PV的绑定就不会丢失

7.创建Pod测试PV的使用

动态卷最终要提供给Pod使用，下面创建一个Pod进行测试

（1）编写PV配置文件

[root@master ~]# cat test-sc-pod.yaml 
kind: Pod
apiVersion: v1
metadata:name: test-sc-pod
spec:containers:- name: test-sc-podimage: busybox:latestcommand:- "/bin/sh"args:- "-c"- "touch /mnt/SUCCESS && exit 0 || exit 1"  # 创建名为"SUCCESS"的文件volumeMounts:- name: nfs-pvcmountPath: "/mnt"restartPolicy: "Never"volumes:- name: nfs-pvcpersistentVolumeClaim:claimName: test-sc-pvc                      # 通过PVC请求PV

（2）执行创建

[root@master ~]# kubectl apply -f test-sc-pod.yaml 
pod/test-sc-pod created

（3）在NFS制备器所挂载的NFS共享目录中查看上述PVC关联的目录

[root@master ~]# ls -l /test-storage/nfs | grep test-sc-pvc
drwxrwxrwx 2 root root   6 5月   4 14:13 default-test-sc-pvc-pvc-d197f44a-1588-47c5-aff9-5bcd85d76443

可以发现，上述NFS制备器创建的目录命名格式为：名称空间名称-PVC名称-PV名称

（4）查看该目录内容，可以发现，Pod已经在其中创建了SUCCESS文件

[root@master ~]# ls -l /test-storage/nfs/default-test-sc-pvc-pvc-d197f44a-1588-47c5-aff9-5bcd85d76443
总用量 0
-rw-r--r-- 1 root root 0 5月   4 16:03 SUCCESS

（5）删除用于测试的Pod和PVC

[root@master ~]# kubectl delete -f test-sc-pod.yaml 
pod "test-sc-pod" deleted
[root@master ~]# kubectl delete -f test-sc-pvc.yaml 
persistentvolumeclaim "test-sc-pvc" deleted

（6）在NFS共享目录中再次查看与上述PVC关联的目录

[root@master ~]# ls -l /test-storage/nfs | grep test-sc-pvc
drwxrwxrwx 2 root root  21 5月   4 16:03 archived-default-test-sc-pvc-pvc-d197f44a-1588-47c5-aff9-5bcd85d76443

可以发现，Kubernetes根据上述StorageClass中关于NFS制备器的存档删除处理参数定义（archiveOnDelete:“true”），自动为基于PVC请求所创建的目录保留了一份存档目录。

（7）清理实验环境

[root@master ~]# kubectl get pods
NAME                                      READY   STATUS                   RESTARTS      AGE
nfs-client-provisioner-548bdbd66c-jst69   1/1     Running                  1 (36m ago)   148m
recycler-for-nfs-pv1                      0/1     ContainerStatusUnknown   0             155m
[root@master ~]# kubectl delete -f deploy/rbac.yaml 
serviceaccount "nfs-client-provisioner" deleted
clusterrole.rbac.authorization.k8s.io "nfs-client-provisioner-runner" deleted
clusterrolebinding.rbac.authorization.k8s.io "run-nfs-client-provisioner" deleted
role.rbac.authorization.k8s.io "leader-locking-nfs-client-provisioner" deleted
rolebinding.rbac.authorization.k8s.io "leader-locking-nfs-client-provisioner" deleted
[root@master ~]# kubectl get pods
NAME                                      READY   STATUS                   RESTARTS      AGE
nfs-client-provisioner-548bdbd66c-jst69   1/1     Running                  1 (36m ago)   149m
recycler-for-nfs-pv1                      0/1     ContainerStatusUnknown   0             156m
[root@master ~]# kubectl delete -f deploy/deployment.yaml 
deployment.apps "nfs-client-provisioner" deleted
[root@master ~]# kubectl get pods
NAME                   READY   STATUS                   RESTARTS   AGE
recycler-for-nfs-pv1   0/1     ContainerStatusUnknown   0          156m
[root@master ~]# kubectl delete pod recycler-for-nfs-pv1
pod "recycler-for-nfs-pv1" deleted
[root@master ~]# kubectl get pods
No resources found in default namespace.
[root@master ~]#