配置和使用持久卷

配置和使用持久卷

文章目錄

  • 配置和使用持久卷
    • @[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.pswp.cn/diannao/81673.shtml
繁體地址，請注明出處：http://hk.pswp.cn/diannao/81673.shtml
英文地址，請注明出處：http://en.pswp.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