Kubernetes 持久化儲存之 NFS 終極實戰指南

kubesphere發表於2024-07-22
持久化NFS

作者：運維有術星主
在 Kubernetes 生態系統中，持久化儲存扮演著至關重要的角色，它是支撐應用穩定執行的基石。對於那些選擇自建 Kubernetes 叢集的運維架構師而言，選擇合適的後端持久化儲存解決方案是一項至關重要的選型決策。後端持久化儲存常見的解決方案有 Ceph、GlusterFS、NFS、hostPath，以及這兩年新興起的 Longhorn。當然，技術領域日新月異，還有其他優秀的解決方案我尚未了解。

今天，我將為大家分享，如何在 Kubernetes 叢集中手動安裝 Kubernetes NFS Subdir External Provisioner 外掛。這是一個強大的工具，能夠實現為 Kubernetes 叢集提供自動化的基於 NFS 儲存的持久化動態卷管理能力。透過實戰演示，您將學會如何將 NFS 作為後端的持久化儲存解決方案整合至 Kubernetes 叢集。

本文核心內容概覽：

  • NFS 持久化儲存選型說明： 理解為什麼選擇 NFS 及其優缺點。
  • NFS 儲存服務如何部署： 如何在 openEuler 上部署配置 NFS 儲存
  • 手動安裝 NFS Subdir External Provisioner：一步步指導如何安裝、配置、解除安裝這一關鍵外掛。
  • 實戰演示：建立測試資源，體驗 NFS 作為持久化儲存的效果。

實戰伺服器配置(架構 1:1 復刻小規模生產環境，配置略有不同)

主機名 IP CPU 記憶體 系統盤 資料盤 用途
ksp-registry 192.168.9.90 4 8 40 200 Harbor 映象倉庫
ksp-control-1 192.168.9.91 4 8 40 100 KubeSphere/k8s-control-plane
ksp-control-2 192.168.9.92 4 8 40 100 KubeSphere/k8s-control-plane
ksp-control-3 192.168.9.93 4 8 40 100 KubeSphere/k8s-control-plane
ksp-worker-1 192.168.9.94 4 16 40 100 k8s-worker/CI
ksp-worker-2 192.168.9.95 4 16 40 100 k8s-worker
ksp-worker-3 192.168.9.96 4 16 40 100 k8s-worker
ksp-storage-1 192.168.9.97 4 8 40 300+ Ceph/Longhorn/NFS/ElasticSearch
ksp-storage-2 192.168.9.98 4 8 40 300+ Ceph/Longhorn/ElasticSearch
ksp-storage-3 192.168.9.99 4 8 40 300+ Ceph/Longhorn/ElasticSearch
ksp-gpu-worker-1 192.168.9.101 4 16 40 100 k8s-worker(GPU NVIDIA Tesla M40 24G)
ksp-gpu-worker-2 192.168.9.102 4 16 40 100 k8s-worker(GPU NVIDIA Tesla P100 16G)
ksp-gateway-1 192.168.9.103 2 4 40 自建應用服務代理閘道器/VIP：192.168.9.100
ksp-gateway-2 192.168.9.104 2 4 40 自建應用服務代理閘道器/VIP：192.168.9.100
ksp-mid 192.168.9.105 4 8 40 100 部署在 k8s 叢集之外的服務節點（Gitlab 等）
合計 15 56 152 600 2000+

實戰環境涉及軟體版本資訊

  • 作業系統：openEuler 22.03 LTS SP3 x86_64
  • KubeSphere：v3.4.1
  • Kubernetes：v1.28.8
  • KubeKey: v3.1.1
  • Containerd：1.7.13
  • NVIDIA GPU Operator：v24.3.0
  • NVIDIA 顯示卡驅動：550.54.15
  • Kubernetes NFS Subdir External Provisioner：4.0.18

1. 前置條件

1.1 NFS 選型說明

本文介紹的內容可直接用於研發、測試環境，對於生產環境不建議使用 NFS 儲存，主要原因如下：

  • 單點故障，生產上使用第一要解決的就是 NFS 單點的問題，有解決方案但是很麻煩，本文不涉及
  • 網路故障，要考慮 NFS 對網路的依賴度，網路波動造成的連線異常等問題
  • 容量限制，無法限制實際的使用容量
  • 儲存的冗餘，要考慮 NFS 底層磁碟是否有冗餘備份
  • 有些元件和應用不相容 NFS 儲存（比如 Promethues，未實際驗證，只是在網上多次看到相關的說明）
  • 效能最佳化（Pod 少的時候還可以，連線掛載點多了怎麼最佳化是個問題）

雖然，我個人不建議在生產環境使用 NFS 作為 Kubernetes 的後端持久化儲存。但是，在我做過的小調研中發現，生產環境使用 NFS 的比率還挺高。

這是為什麼呢？我左思右想可能的原因有：

  • NFS 簡單易維護
  • 使用 NFS 的生產環境對於業務的中斷和資料的丟失有一定的容忍度（或許對中斷和資料丟失都有對應的應對方案）
  • 成本低廉，降本增效（笑）。一臺或兩臺儲存就能搞定，比 Ceph、GlusterFS 動輒三臺起步需要的資源少的太多了（但是也要考慮，因為儲存導致叢集故障從而導致業務故障的後果）

生產環境一定要使用 NFS？建議仔細考慮以下幾點：

  • 建議選擇硬體廠商的商業集中式儲存產品不要自建
  • 儲存網路一定要使用萬兆網路，且有網路卡冗餘 bond 加持
  • 自建的 NFS 儲存資料盤一定要做 Raid，最好 Raid10
  • 業務應用對儲存 IO 能力要求高時，不要使用 NFS
  • 是否需要 NFS 服務的高可用？如何實現？

1.2 安裝 NFS 客戶端

在安裝 Kubernetes NFS Subdir External Provisioner 之前，Kubernetes 叢集所有節點需要提前安裝 NFS 客戶端，否則部署過程會報錯。不同作業系統 NFS 客戶端的包名不同，CentOS 和 openEuler 中包名為 nfs-utils。

  • 安裝 NFS 客戶端
yum install nfs-utils

2. openEuler 部署 NFS 服務

本文的主要目的是測試 Kubernetes 使用 NFS 作為持久化儲存的能力。因此，實戰環境選擇一臺作業系統為 openEuler 的虛擬機器部署 NFS 服務。該 NFS 伺服器安裝配置方法僅適用於測試環境，生產環境請謹慎評估、配置使用。

本文使用 IP 為 192.168.9.97 的 ksp-storage-1 節點， 部署單節點 NFS 儲存伺服器。部署過程中分配一塊獨立的 100G 資料盤 /dev/sde, 使用 LVM 型別將其格式化，掛載到 /datanfs/ 目錄下作為共享儲存的根目錄。

2.1 初始化資料盤

LVM 配置比較簡單，操作細節不做解釋，直接上命令。

pvcreate /dev/sde
vgcreate datanfs /dev/sde
lvcreate -l 100%VG datanfs -n lvnfs
mkfs.xfs /dev/mapper/datanfs-lvnfs
mkdir /datanfs/
mount /dev/mapper/datanfs-lvnfs /datanfs/
tail -1 /etc/mtab >> /etc/fstab

2.2 安裝 NFS 服務端軟體包

yum install nfs-utils

2.3 建立共享資料根目錄

執行以下命令，建立共享資料儲存目錄，本文以 /datanfs/k8s 為例，請根據實際情況調整路徑和許可權。

mkdir -p /datanfs/k8s
chown nobody:nobody /datanfs/k8s

2.4 編輯服務配置檔案

配置 NFS 伺服器資料匯出目錄及訪問 NFS 伺服器的客戶端機器許可權。

編輯配置檔案 vi /etc/exports，新增如下內容：

/datanfs/k8s 192.168.9.0/24(rw,sync,all_squash,anonuid=65534,anongid=65534,no_subtree_check)

配置說明：

  • /datanfs/k8s：NFS 匯出的共享資料目錄
  • 192.168.9.0/24：可以訪問 NFS 儲存的客戶端 IP 地址
  • rw：讀寫操作，客戶端機器擁有對卷的讀寫許可權。
  • sync：記憶體資料實時寫入磁碟，效能會有所限制
  • all_squash：NFS 客戶端上的所有使用者在使用共享目錄時都會被轉換為一個普通使用者的許可權
  • anonuid：轉換後的使用者許可權 ID，對應的作業系統的 nobody 使用者
  • anongid：轉換後的組許可權 ID，對應的作業系統的 nobody 組
  • no_subtree_check：不檢查客戶端請求的子目錄是否在共享目錄的子樹範圍內，也就是說即使輸出目錄是一個子目錄，NFS 伺服器也不檢查其父目錄的許可權，這樣可以提高效率。

2.5 啟動服務並設定開機自啟

systemctl enable nfs-server --now

2.6 檢視共享目錄

  • 檢視匯出目錄
exportfs -v

正確執行後，輸出結果如下 :

$ exportfs -v
/datanfs/k8s    192.168.9.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,all_squash)

2.7 客戶端掛載測試

找一臺額外的機器作為客戶端驗證測試，本示例使用 ksp-worker-1 節點。

  • 建立測試掛載點
mkdir /mnt/nfs
  • 安裝 NFS 軟體包（一定要安裝，否則無法識別 nfs 型別的儲存）
yum install nfs-utils
  • 檢視 NFS 共享目錄列表
$showmount -e 192.168.9.97
Export list for 192.168.9.97:
/datanfs/k8s 192.168.9.0/24
  • 掛載 NFS 共享目錄
mount -t nfs 192.168.9.97:/datanfs/k8s /mnt/nfs/
  • 增刪改查測試
# 建立測試目錄、建立測試檔案、測試檔案寫入內容、檢視寫入目錄和檔案許可權、刪除目錄和檔案
# 建立
mkdir /mnt/nfs/nfs-test
touch /mnt/nfs/nfs-test.txt
echo "nfs-test" > nfs-test.txt

# 檢視
$ ls -l /mnt/nfs/
total 4
drwxr-xr-x 2 nobody nobody 6 Jul 11 21:37 nfs-test
-rw-r--r-- 1 nobody nobody 9 Jul 11 21:37 nfs-test.txt

$ cat /mnt/nfs/nfs-test.txt
nfs-test

# 刪除
rmdir /mnt/nfs/nfs-test
rm -rf /mnt/nfs/nfs-test.txt
  • 解除安裝 NFS 儲存
umount /mnt/nfs/

3. 安裝配置 Kubernetes NFS Subdir External Provisioner

Kubernetes 支援 NFS 儲存，需要安裝 nfs-subdir-external-provisioner ，它是一個儲存資源自動調配器，它可將現有的 NFS 伺服器透過持久卷宣告來支援 Kubernetes 持久卷的動態分配。該元件是對 Kubernetes NFS-Client Provisioner 的擴充套件， nfs-client-provisioner 已經不提供更新，而且 nfs-client-provisioner Github 倉庫 也已經處於歸檔狀態，已經遷移到 nfs-subdir-external-provisioner 的倉庫。

官方提供的安裝方式有三種：

  • With Helm
  • With Kustomize
  • Manually

使用 Helm 的方式比較簡單，也是現在官方推薦的、使用率最高的方式。

往期我已經分享過如何使用 Helm 的方式部署 NFS Subdir External Provisioner。所以，今天實戰演示如何手動部署。

其實，我個人更喜歡手動部署，手動方式更靈活，適用於沒有 Helm 或是跟我一樣不願意用 Helm 的離線或線上環境。

3.1 獲取 NFS Subdir External Provisioner 部署檔案

在 K8S 控制節點 ksp-control-1 ，下載最新版 nfs-subdir-external-provisioner-4.0.18 Releases 檔案，並解壓。

wget https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/archive/refs/tags/nfs-subdir-external-provisioner-4.0.18.zip
unzip nfs-subdir-external-provisioner-4.0.18.zip
cd nfs-subdir-external-provisioner-nfs-subdir-external-provisioner-4.0.18/

3.2 建立 NameSpace

可選配置，預設為 default，新建方便資源管理。

kubectl create ns nfs-system

3.3 配置 RBAC authorization

  • 替換名稱空間名稱
 sed -i'' "s/namespace:.*/namespace: nfs-system/g" ./deploy/rbac.yaml ./deploy/deployment.yaml
  • 建立 RBAC 資源
kubectl create -f deploy/rbac.yaml

3.4 配置 NFS subdir external provisioner

編輯 provisioner's deployment 檔案 deploy/deployment.yaml，重點修改以下內容：

  • image: 預設使用 registry.k8s.io 映象倉庫的映象 nfs-subdir-external-provisioner:v4.0.2，網路受限時需要想辦法下載並上傳到方便訪問的映象倉庫
  • NFS 伺服器的主機名或是 IP 地址
  • NFS 伺服器匯出的共享資料目錄的路徑（exportfs）

檔案 deployment.yaml 預設內容如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: nfs-system
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 10.3.243.101
            - name: NFS_PATH
              value: /ifs/kubernetes
      volumes:
        - name: nfs-client-root
          nfs:
            server: 10.3.243.101
            path: /ifs/kubernetes

說明： 主要修改內容，用實際 NFS 配置資訊替換預設值（受限於篇幅，未展示最終修改後的內容）

  • image: registry.k8s.io/sig-storage/nfs-subdir-external-provisioner:v4.0.2

  • value: 10.3.243.101

  • value: /ifs/kubernetes

3.5 部署 NFS Subdir External Provisioner

  • 執行部署命令
 kubectl apply -f deploy/deployment.yaml
  • 檢視 deployment、pod 部署結果
$ kubectl get deployment,pods -n nfs-system
NAME                                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/nfs-client-provisioner   1/1     1            1           41s

NAME                                          READY   STATUS    RESTARTS   AGE
pod/nfs-client-provisioner-75df4c7d5b-nc2ts   1/1     Running   0          41s

3.6 部署 Storage Class

Step 1: 編輯 NFS subdir external provisioner 定義 Kubernetes Storage Class 的配置檔案 deploy/class.yaml，重點修改以下內容：

  • 儲存類名稱
  • 儲存卷刪除後的預設策略

檔案預設內容如下：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"

修改後的檔案內容如下：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-sc
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "true"

說明： 主要修改內容

  • metadata.name，設定儲存類的名稱為 nfs-sc
  • parameters.archiveOnDelete，設定為 true

重點說說 Parameters archiveOnDelete 的配置。

  • 該值為 false 時，儲存卷刪除時，在 NFS 上直接刪除對應的資料目錄
  • 該值為 true 時，儲存卷刪除時，在 NFS 上以 archived-<volume.Name> 的命名規則，歸檔保留原有的資料目錄
  • 具體如何設定請一定結合自己的實際環境酌情處理，資料量小的場景下，個人喜歡設定為 true，手動或自動定時清理歸檔資料。

Parameters 所有可選設定項如下所示，各位可自行研究、使用:

Name Description Default
onDelete If it exists and has a delete value, delete the directory, if it exists and has a retain value, save the directory. will be archived with name on the share: archived-<volume.Name>
archiveOnDelete If it exists and has a false value, delete the directory. if onDelete exists, archiveOnDelete will be ignored. will be archived with name on the share: archived-<volume.Name>
pathPattern Specifies a template for creating a directory path via PVC metadata's such as labels, annotations, name or namespace. To specify metadata use ${.PVC.<metadata>}. Example: If folder should be named like <pvc-namespace>-<pvc-name>, use ${.PVC.namespace}-${.PVC.name} as pathPattern. n/a

Step 2: 執行部署命令，部署 Storage Class。

kubectl apply -f deploy/class.yaml

檢視 Storage Class 部署結果。

$ kubectl get sc
NAME                 PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local (default)      openebs.io/local                              Delete          WaitForFirstConsumer   false                  50d
nfs-sc               k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate              false                  19s

4. 驗證測試

4.1 建立測試 PVC

  • 編寫測試 PVC 資源清單，vi test-nfs-pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: test-nfs-pvc
spec:
  storageClassName: nfs-sc
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
  • 建立 PVC
kubectl apply -f test-nfs-pvc.yaml
  • 檢視 PVC
$ kubectl get pvc -o wide
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE   VOLUMEMODE
test-nfs-pvc   Bound    pvc-6b7abed8-805e-45ff-82c8-1ad3beca8b9e   1Gi        RWX            nfs-sc         10s   Filesystem

4.2 建立測試 Pod

  • 編寫測試 Pod 資源清單，vi test-nfs-pod.yaml
kind: Pod
apiVersion: v1
metadata:
  name: test-nfs-pod
spec:
  containers:
  - name: test-nfs-pod
    image: busybox:stable
    command:
      - "/bin/sh"
    args:
      - "-c"
      - "touch /mnt/SUCCESS && sleep 3600"
    volumeMounts:
      - name: nfs-pvc
        mountPath: "/mnt"
  restartPolicy: "Never"
  volumes:
    - name: nfs-pvc
      persistentVolumeClaim:
        claimName: test-nfs-pvc
  • 建立 Pod
kubectl apply -f test-nfs-pod.yaml
  • 檢視 Pod
$ kubectl get pods -o wide
NAME           READY   STATUS    RESTARTS   AGE   IP              NODE           NOMINATED NODE   READINESS GATES
test-nfs-pod   1/1     Running   0          5s    10.233.68.152   ksp-worker-2   <none>           <none>
  • 檢視 Pod 掛載的儲存
$ kubectl exec test-nfs-pod -- df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                  99.9G      6.6G     93.3G   7% /
tmpfs                    64.0M         0     64.0M   0% /dev
tmpfs                     7.6G         0      7.6G   0% /sys/fs/cgroup
192.168.9.97:/datanfs/k8s/default-test-nfs-pvc-pvc-6b7abed8-805e-45ff-82c8-1ad3beca8b9e
                         99.9G    746.0M     99.2G   1% /mnt
/dev/mapper/openeuler-root
                         34.2G      2.2G     30.2G   7% /etc/hosts
/dev/mapper/openeuler-root
                         34.2G      2.2G     30.2G   7% /dev/termination-log
/dev/mapper/data-lvdata
                         99.9G      6.6G     93.3G   7% /etc/hostname
/dev/mapper/data-lvdata
                         99.9G      6.6G     93.3G   7% /etc/resolv.conf
shm                      64.0M         0     64.0M   0% /dev/shm
tmpfs                    13.9G     12.0K     13.9G   0% /var/run/secrets/kubernetes.io/serviceaccount
tmpfs                     7.6G         0      7.6G   0% /proc/acpi
tmpfs                    64.0M         0     64.0M   0% /proc/kcore
tmpfs                    64.0M         0     64.0M   0% /proc/keys
tmpfs                    64.0M         0     64.0M   0% /proc/timer_list
tmpfs                    64.0M         0     64.0M   0% /proc/sched_debug
tmpfs                     7.6G         0      7.6G   0% /proc/scsi
tmpfs                     7.6G         0      7.6G   0% /sys/firmware

注意： 在輸出結果中我們可以看到掛載的 NFS 儲存的可用空間為 99.9G，而不是我們 PVC 中分配的 1G。

  • 測試儲存空間是否能超限（分配 1G，使用 2G）
# 寫入 2G 的資料
$ kubectl exec test-nfs-pod -- dd if=/dev/zero of=/mnt/test-nfs.img bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2.0GB) copied, 2.731103 seconds, 732.3MB/s

# 檢視結果
$ kubectl exec test-nfs-pod -- ls -lh /mnt/
total 2G
-rw-r--r--    1 nobody   nobody         0 Jul 11 21:45 SUCCESS
-rw-r--r--    1 nobody   nobody      2.0G Jul 11 21:47 test-nfs.img

注意： 實際測試我們寫入了 2G 的資料量，已經超過了我們建立的 PVC 1G 的限制。因此，要特別注意，使用 NFS 儲存時無法限制儲存使用量。

4.3 儲存節點檢視驗證

SSH 登陸 NFS 儲存伺服器（ ksp-storage-1 節點），執行以下命令。

# 檢視 NFS 匯出資料根目錄
$ ls -l /datanfs/k8s/
total 0
drwxrwxrwx. 2 nobody nobody 41 Jul 11 21:47 default-test-nfs-pvc-pvc-6b7abed8-805e-45ff-82c8-1ad3beca8b9e

# 檢視分配的 PVC 資料目錄
$ ls -l /datanfs/k8s/default-test-nfs-pvc-pvc-6b7abed8-805e-45ff-82c8-1ad3beca8b9e/
total 2048000
-rw-r--r--. 1 nobody nobody          0 Jul 11 21:45 SUCCESS
-rw-r--r--. 1 nobody nobody 2097152000 Jul 11 21:47 test-nfs.img

在輸出結果中，可以看見 SUCCESS 和 test.img 兩個檔案，並且可以看出命名目錄的規則為 namespace 名稱-pvc 名稱-pv 名稱。

PV 名稱格式是 pvc+隨機字串，所以，每次只要不刪除 PVC，那麼 Kubernetes 中 PV 與儲存繫結將不會丟失，要是刪除 PVC 也就意味著刪除了繫結的資料夾，下次就算重新建立相同名稱的 PVC，生成的資料夾名稱也不會一致，因為 PV 名是隨機生成的字串，而資料夾命名又跟 PV 有關，所以刪除 PVC 需謹慎。

4.4 清理測試資源

  • 清理測試 Pod、PVC
kubectl delete -f test-nfs-pod.yaml  -f test-nfs-pvc.yaml
  • 在 NFS 儲存伺服器檢視資料目錄
# 檢視 NFS 匯出資料根目錄
$ ls -l /datanfs/k8s/
total 0
drwxrwxrwx. 2 nobody nobody 41 Jul 11 21:47 archived-default-test-nfs-pvc-pvc-6b7abed8-805e-45ff-82c8-1ad3beca8b9e

# 檢視刪除的 PVC 資料目錄
$ ls -l /datanfs/k8s/archived-default-test-nfs-pvc-pvc-6b7abed8-805e-45ff-82c8-1ad3beca8b9e/
total 2048000
-rw-r--r--. 1 nobody nobody          0 Jul 11 21:45 SUCCESS
-rw-r--r--. 1 nobody nobody 2097152000 Jul 11 21:47 test-nfs.img

從結果中可以看到，Kubernetes 刪除 PVC 後，在 NFS 儲存層並沒有立即刪除 PVC 對應的資料目錄及資料，而是將原來的資料目錄改名為 archived-+原有資料目錄名稱的形式。

該結果與我們配置 Storage Class 時，將引數 archiveOnDelete 值設定為 true 的預期相符（你可以可自行測試其他引數和值的配置效果）。

5. KubeSphere 控制檯管理儲存資源

5.1 管理儲存類

在控制檯左側功能選單，依次選擇「叢集」->「儲存」->「儲存類」。

5.2 建立持久卷宣告（PVC）

Step 1: 在控制檯左側功能選單，依次選擇「叢集」->「儲存」->「持久卷宣告」，點選「建立」按鈕。

  • 按提示填寫基本資訊

  • 按提示填寫儲存設定，儲存類選擇 nfs-sc，容量選擇 2G

  • 高階設定保持預設，點選「建立」

Step 2: 建立完成後，檢視已經建立的 PVC、PV 及詳情。

  • 已建立的 PVC 列表

  • 已建立的 PV 列表

  • 檢視 nfs-test-pvc1 詳情（未掛載使用，所以顯示容量為 0）

  • 建立一個 Pod，掛載 nfs-test-pvc1，再次檢視詳情。

容量顯示 NFS 儲存空間的總容量、剩餘容量、已使用百分比，並不是單個 PV 的容量資訊。初始測試時佔用 2G 未刪除，因此 NFS 儲存空間總體分配了 4G，顯示結果略有差異也屬於正常現象。

6. 解除安裝 NFS Subdir External Provisioner

6.1 解除安裝前提條件

當需要解除安裝 NFS Subdir External Provisioner 時，先確認滿足以下前提條件。

  • 清理所有使用 PVC 資源的 Pod（謹慎操作）
  • 清理所有的 PVC（可以選擇在 KubeSphere 的管理控制檯頁面中清理，視覺化更全面、更清晰）
  • 手工清理 NFS 儲存中殘留的以 archived- 命名的所有資料目錄（可選，謹慎操作）

6.2 解除安裝 NFS Subdir External Provisioner

按順序執行資源刪除命令， 解除安裝 NFS Subdir External Provisioner。

  • 刪除 Storage Class
kubectl delete -f deploy/class.yaml
  • 刪除 NFS Subdir External Provisioner
kubectl delete -f deploy/deployment.yaml
  • 刪除 RBAC authorization 配置
kubectl delete -f deploy/rbac.yaml
  • 驗證資源是否解除安裝
$ kubectl get deploy,pod,sc -n nfs-system
NAME                                          PROVISIONER        RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
storageclass.storage.k8s.io/local (default)   openebs.io/local   Delete          WaitForFirstConsumer   false                  22h

說明： 結果中顯示的是預設的 openebs 儲存，nfs 相關資源已經刪除

  • 刪除 NameSpace（如果有，可選）
kubectl delete ns nfs-system

免責宣告：

  • 筆者水平有限，儘管經過多次驗證和檢查，盡力確保內容的準確性，但仍可能存在疏漏之處。敬請業界專家大佬不吝指教。
  • 本文所述內容僅透過實戰環境驗證測試，讀者可學習、借鑑，但嚴禁直接用於生產環境。由此引發的任何問題，作者概不負責！

本文由部落格一文多發平臺 OpenWrite 釋出！

相關文章