配置和使用持久卷

配置和使用持久卷

文章目录

  • 配置和使用持久卷
    • @[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） 是持久化存储的核心机制，旨在解耦存储资源的管理与使用，

  1. 核心概念与职责分离
  • PV（持久卷）
    由管理员创建和维护，代表集群中的实际存储资源（如 NFS、云存储等），定义存储容量、访问模式、回收策略等属性。PV 的生命周期独立于 Pod，即使 Pod 被删除，数据仍可保留。
  • PVC（持久卷声明）
    由用户创建，声明存储需求（如容量、访问模式），Kubernetes 会根据 PVC 的请求自动绑定符合条件的 PV。PVC 屏蔽了底层存储细节，用户无需关心具体存储类型。
  1. 生命周期与绑定机制
  • 资源供应
    • 静态供应：管理员预先创建 PV，用户通过 PVC 申请。
    • 动态供应：通过 StorageClass 动态创建 PV。用户只需指定 StorageClass 模板，系统按需生成 PV 并与 PVC 绑定。
  • 绑定规则
    • PVC 需与 PV 的 访问模式（如 ReadWriteOnce、ReadOnlyMany）、存储容量 和 StorageClass 匹配。
    • 绑定后，PV 被独占使用，无法与其他 PVC 绑定。
  1. 关键配置参数
  • PV 配置
    • 访问模式：定义存储的挂载权限（如单节点读写、多节点只读）。
    • 回收策略
      • Retain：保留数据，需手动清理；
      • Delete：自动删除存储资源；
      • Recycle（已废弃）：数据擦除后重新可用。
    • StorageClass：用于动态供应时分类存储特性（如性能等级）。
  • PVC 配置
    • 需声明 存储容量、访问模式，并可通过标签筛选特定 PV。
  1. 使用场景与优势
  • 数据持久化：适用于数据库、日志存储等需保留数据的场景。
  • 共享存储：多个 Pod 通过 PVC 共享同一 PV（需支持多节点访问模式，如 NFS）。
  • 解耦管理：存储管理员负责 PV 运维，开发者通过 PVC 按需申请资源。
  1. 回收与维护
  • PVC 删除后
    • 若 PV 回收策略为 Retain，需手动清理数据并删除 PV；
    • 若为 Delete，则自动释放存储资源。

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

二、PV和PVC的生命周期

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

一、PV 生命周期

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

二、PVC 生命周期

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

三、关键状态与策略对比

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

四、生产实践建议

  1. 优先使用动态供应：通过 StorageClass 自动化 PV 创建，避免资源浪费。
  2. 合理设置回收策略：生产环境推荐 Retain 策略防止误删数据，测试环境可用 Delete 策略。
  3. 监控 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被命名为 n a m e s p a c e − {namespace}- 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 ~]#

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/diannao/81673.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

FreeRTOS菜鸟入门（十）·消息队列

FreeRTOS菜鸟入门（十）·消息队列

目录 1. 基本概念 2. 数据存储 3. 运作机制 4. 阻塞机制 4.1 出队阻塞 4.2 入队阻塞 5. 操作示意图 5.1 创建队列 5.2 向队列发送第一个消息 5.3 向队列发送第二个消息 5.4 从队列读取消息 6. 消息队列控制块 7. 消息队列常用函数 7.1 消息队列创建…
阅读更多...
java 洛谷题单【算法2-2】常见优化技巧

java 洛谷题单【算法2-2】常见优化技巧

P1102 A-B 数对 解题思路 输入读取与初始化&#xff1a; 使用 Scanner 读取输入。n 表示数组的长度&#xff0c;c 表示目标差值。使用一个 HashMap 存储数组中每个数字及其出现的次数&#xff0c;方便快速查找。数组 a 用于存储输入的数字。 构建哈希映射&#xff1a; 遍历数…
阅读更多...
视频转GIF

视频转GIF

视频转GIF 以下是一个使用 Python 将视频转换为 GIF 的脚本&#xff0c;使用了 imageio 和 opencv-python 库&#xff1a; import cv2 import imageio import numpy as np """将视频转换为GIF图参数:video_path -- 输入视频的路径gif_path -- 输出GIF的路径fp…
阅读更多...
计算机网络：详解TCP协议（四次握手三次挥手）

计算机网络：详解TCP协议（四次握手三次挥手）

目录 1.Tcp协议介绍 1.1 Tcp协议层级 1.2 TCP协议的格式 2. 确认应答机制 2.1 确认应答 2.2 序号字段 2.3 捎带应答 3. 流量控制 4. 三次握手 四次挥手 4.1 认识标志位 4.2 简单认识 4.3 三次挥手 4.4 四次挥手 1.Tcp协议介绍 1.1 Tcp协议层级 计算机网络&#x…
阅读更多...
小程序 IView WeappUI组件库(简单增删改查)

小程序 IView WeappUI组件库(简单增删改查)

IView Weapp 微信小程序UI组件库&#xff1a;https://weapp.iviewui.com/components/card IView Weapp.png 快速上手搭建 快速上手.png iView Weapp 的代码 将源代码下载下来&#xff0c;然后将dict放到自己的项目中去。 iView Weapp 的代码.png 小程序中添加iView Weapp 将di…
阅读更多...
用java实现一个简单的sql select 解析器,无需第三方依赖，完全从0开始

用java实现一个简单的sql select 解析器,无需第三方依赖，完全从0开始

以下是一个简单的 SQL SELECT 解析器的 Java 实现&#xff0c;支持单表查询和基本条件过滤。代码包含词法分析和语法分析模块&#xff0c;并支持以下语法&#xff1a; SELECT column1, column2 FROM table WHERE column3 5 完整代码 1. Token 类型定义 (TokenType.java) pu…
阅读更多...
阿里云 CentOS YUM 源配置指南

阿里云 CentOS YUM 源配置指南

阿里云 CentOS YUM 源配置指南 在使用 CentOS 7 时&#xff0c;由于 CentOS 官方源停止维护等原因&#xff0c;yum install 命令可能会报错 “Cannot find a valid baseurl for repo: centos-sclo-rh/x86_64”。以下是通过更换阿里云源解决该问题的详细步骤。 一、备份原有配…
阅读更多...
Learning vtkjs之ThresholdPoints

Learning vtkjs之ThresholdPoints

过滤器 阈值过滤器 介绍 vtkThresholdPoints - 提取满足阈值条件的点 vtkThresholdPoints 是一个过滤器&#xff0c;它从数据集中提取满足阈值条件的点。该条件可以采用三种形式&#xff1a; 1&#xff09;大于特定值&#xff1b; 2) 小于特定值&#xff1b; 3) 在特定值之间…
阅读更多...
记录ruoyi-flowable-plus第一次运行流程报错

记录ruoyi-flowable-plus第一次运行流程报错

记录ruoyi-flowable-plus第一次运行流程报错 错误步骤 1.启动ruoyi-flowable-plus 正常登录后&#xff0c;打开流程分类然后点击新增按钮&#xff0c;新增了一个分类。增加成功后&#xff0c; 再点击流程分类&#xff0c;报错。 错误提示 org.springframework.cglib.core.C…
阅读更多...
Java中的stream流介绍与使用

Java中的stream流介绍与使用

一、Stream 的基础概念 定义与特性 Stream 是单向数据流&#xff0c;对集合或数组进行高效处理&#xff0c;不存储数据&#xff0c;而是通过操作链生成新 Stream。不可变性&#xff1a;原始数据源不被修改&#xff0c;所有操作均返回新 Stream。延迟执行&#xff1a;中间操作&a…
阅读更多...
OCR身份证识别（正反面）_个人证照OCR识别_开放API接口使用指南

OCR身份证识别（正反面）_个人证照OCR识别_开放API接口使用指南

一、接口简介 在数字化时代&#xff0c;快速准确地提取身份证信息变得尤为重要。**万维易源提供的“身份证OCR识别”API接口&#xff0c;能够快速提取二代居民身份证正反面的所有字段信息&#xff0c;包括姓名、性别、民族、出生日期、住址、身份证号、签发机关、有效期限等。…
阅读更多...
25年新版潮乎盲盒系统源码 盲盒商城系统前端分享

25年新版潮乎盲盒系统源码 盲盒商城系统前端分享

盲盒系统市场的前景一直都很不错&#xff0c;最近很多问我有没有盲盒源码的客户&#xff0c;下面给大家分享一个新版潮乎盲盒源码&#xff01; 这款盲盒源码系统 前端Uniapp 后端使用了Laravel框架进行开发。Laravel是一个流行的PHP框架&#xff0c;具有强大的功能和易于使用的…
阅读更多...
Transformer四模型回归打包（内含NRBO-Transformer-GRU、Transformer-GRU、Transformer、GRU模型）

Transformer四模型回归打包（内含NRBO-Transformer-GRU、Transformer-GRU、Transformer、GRU模型）

Transformer四模型回归打包&#xff08;内含NRBO-Transformer-GRU、Transformer-GRU、Transformer、GRU模型&#xff09; 目录 Transformer四模型回归打包&#xff08;内含NRBO-Transformer-GRU、Transformer-GRU、Transformer、GRU模型&#xff09;预测效果基本介绍程序设计参…
阅读更多...
Axure疑难杂症：利用中继器制作三级下拉菜单（逻辑判断进阶）

Axure疑难杂症：利用中继器制作三级下拉菜单（逻辑判断进阶）

亲爱的小伙伴，在您浏览之前，烦请关注一下，在此深表感谢！ Axure产品经理精品视频课已登录CSDN可点击学习https://edu.csdn.net/course/detail/40420 课程主题：三级下拉菜单 主要内容：条件筛选时的逻辑判断思维，中继器使用 应用场景：复合条件下的下拉列表制作 案例展…
阅读更多...
Nginx 核心功能之正反代理

Nginx 核心功能之正反代理

目录 一、Nginx 二、正向代理 三、反向代理 四、Nginx 缓存 1. 缓存功能的核心原理和缓存类型 2. 代理缓存功能设置 五、Nginx rewrite和正则 &#xff08;1&#xff09;Nginx 正则 &#xff08;2&#xff09;nginx location &#xff08;3&#xff09;Rewrite &…
阅读更多...
ssh连接云服务器记录

ssh连接云服务器记录

文章目录 1. 背景2. ssh连接2.1 win 下通过终端工具进行连接2.2 Linux下通过ssh指令连接2.3 ssh使用publickey来连接 ssh连接云服务器记录 1. 背景 最近开始接触docker技术、mysql技术&#xff0c;加上本人工作基本都在Linux下进行&#xff0c;因此需要一套Linux环境进行练习。…
阅读更多...
软考-软件设计师中级备考 12、软件工程

软考-软件设计师中级备考 12、软件工程

一、软件工程概述 定义&#xff1a;软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量软件的学科。它涉及到软件的开发、测试、维护、管理等多个方面&#xff0c;旨在运用一系列科学方法和技术手段&#xff0c;提高软件的质量和开发效率&#xff0c;降低软件开…
阅读更多...
【多次弹出“获取打开此tobiieyetracking链接的应用”的窗口】解决办法

【多次弹出“获取打开此tobiieyetracking链接的应用”的窗口】解决办法

使用联想R9000P突然出现“获取打开此tobiieyetracking链接的应用”的窗口&#xff0c;每隔几分钟就弹一次&#xff0c;特别恶心人&#xff0c;解决办法&#xff1a; 找到【此电脑】&#xff0c;鼠标右键【管理】&#xff1b;选择【服务】&#xff0c;如下所示&#xff0c;找到…
阅读更多...
项目选择的三个核心因素：市场前景、竞争优势和成本控制

项目选择的三个核心因素：市场前景、竞争优势和成本控制

能保持持续增长和赚钱的项目就是好项目。 每个创业者创业之初&#xff0c;遇到的第一个难题就是选择做什么项目&#xff1f; 俗话说&#xff1a;方向不对&#xff0c;努力白费。 选错项目&#xff0c;意味着你所有的付出都是打水漂。 能做的项目那么多&#xff0c;在没有价值…
阅读更多...
裸机 Kubernetes 集群负载均衡器：MetalLB 深度解析与实战指南

裸机 Kubernetes 集群负载均衡器：MetalLB 深度解析与实战指南

一、引言 在云原生架构中&#xff0c;Kubernetes 默认的负载均衡能力依赖于云厂商&#xff08;如 AWS ELB、GCP LB&#xff09;&#xff0c;但在裸机或本地数据中心环境中&#xff0c;这一功能缺失导致 LoadBalancer 类型的 Service 始终处于 Pending 状态。此时&#xff0c;M…
阅读更多...
最新文章

Copyright @ 2022~2023