Storage

NFS 伺服器和客戶端都在工作，但數據不在伺服器上？

  • January 8, 2020

我有一個在裸機上執行的內部 Kubernetes 集群，它由 5 個節點（1 個主節點和 4 個工作節點）組成。我在 master 上本地設置了一個 NFS 伺服器，並在 K8s 中啟動了 nfs-client 以擁有 nfs 動態配置器。一切正常，我可以通過定義持久卷聲明來使用我的應用程序，但我無法在磁碟上找到我的數據。

每次我啟動應用程序時，nfs-client 都會在我的 nfs 伺服器路徑上創建一個具有正確名稱的新目錄，但所有這些目錄都是空的。所以我的問題是我的數據在哪裡？

我正在使用nfs 客戶端的掌舵圖。這是在我的 nfs 伺服器路徑中創建但為空的目錄的範例：

/var/nfs/general$ tree
.
├── 166-postgres-claim-pvc-37146254-db50-4293-a9f7-13097689610a
│   └── data
├── 166-registry-claim-pvc-fe337e34-d9a5-4266-8178-f67973894584
├── 166-registry-slave-claim-registry-slave-0-pvc-b18d430b-e1fc-4eeb-bd12-cab9340bed69
├── 166-rtspdata-claim-pvc-bf9bc1e3-412f-4627-ade4-50817478308e
├── 172-postgres-claim-pvc-087538cf-5b67-4789-8d8b-117d41c3fe02
│   └── data
├── 172-registry-claim-pvc-7b7d9bb6-a636-4f78-b2fe-924473cb47ab
├── 172-registry-slave-claim-registry-slave-0-pvc-34e62524-fca0-48dd-ba29-b4cf178ca028
├── 172-rtspdata-claim-pvc-211a1aac-409f-431c-b78d-5b87b9017625
├── 173-postgres-claim-pvc-b901449a-0ce7-4ecf-8dfc-e6371dd3a9b4
│   └── data
├── 173-registry-claim-pvc-cd842cde-a3f7-4d54-94d6-c018e42ec495
├── 173-rtspdata-claim-pvc-a95c5748-ebed-4045-98b2-a04e534e0cf6
├── archived-161-postgres-claim-pvc-01cc1ff2-8cc8-4161-8d85-00cb6562e10e
│   └── data
├── archived-161-registry-claim-pvc-9b626e01-a565-4214-b94e-b7ba1e206a5e
├── archived-161-rtspdata-claim-pvc-b079c7e2-248e-4245-b243-5ff7dc3afa82
├── archived-162-postgres-claim-pvc-188af7ca-106d-4f2f-8905-9d7b391e9dce
│   └── data
├── archived-162-postgres-claim-pvc-356e4632-19e2-4ac9-8400-e00d39621b7c
│   └── data
├── archived-162-postgres-claim-pvc-45372032-979f-4ced-be35-15ec67a322b7
│   └── data
├── archived-162-postgres-claim-pvc-6d5e1f01-ad5b-45cc-9eef-654275e3ecd2
│   └── data
├── archived-162-postgres-claim-pvc-cbf4d4ca-b9d1-4d1c-88be-621eeb3680fb
│   └── data
├── archived-162-postgres-claim-pvc-eaa32a4c-9768-469a-ad85-1e1b682c376d
│   └── data
├── archived-162-postgres-claim-pvc-f517586b-e132-4a38-8ec9-18f6d5ca000e
│   └── data
├── archived-162-registry-claim-pvc-1796642a-d639-4ede-8204-1779c029aa4e
│   └── rethinkdb_data

我已經在我的測試環境中重現了這個場景，我可以正常找到我的數據。為了重現它，我遵循了這些步驟。

確保您遵循每個步驟。編輯這個文件需要root權限；因此，您需要在命令中使用 sudo。您還可以在任何個人喜歡的文本編輯器中打開該文件。

1 - 在我的主節點上安裝和配置我的 NFS 伺服器（Debian Linux，這可能會根據您的 Linux 發行版而改變）：

在安裝 NFS Kernel 伺服器之前，我們需要更新系統的儲存庫索引：

$ sudo apt-get update

現在，執行以下命令以在您的系統上安裝 NFS 核心伺服器：

$ sudo apt install nfs-kernel-server

創建導出目錄

$ sudo mkdir -p /mnt/nfs_server_files

由於我們希望所有客戶端都可以訪問該目錄，因此我們將通過以下命令刪除導出文件夾的限制性權限（根據您的安全策略，這可能因您的設置而異）：

$ sudo chown nobody:nogroup /mnt/nfs_server_files
$ sudo chmod 777 /mnt/nfs_server_files

通過 NFS 導出文件將伺服器訪問權分配給客戶端

$ sudo nano /etc/exports

在此文件中，添加一個新行以允許從其他伺服器訪問您的共享。

/mnt/nfs_server_files        10.128.0.0/24(rw,sync,no_subtree_check)

您可能希望在共享中使用不同的選項。10.128.0.0/24 是我的k8s內網。

導出共享目錄並重新啟動服務以確保所有配置文件都正確。

$ sudo exportfs -a
$ sudo systemctl restart nfs-kernel-server

檢查所有活動共享：

$ sudo exportfs
/mnt/nfs_server_files
               10.128.0.0/24

2 - 在我的所有工作節點上安裝 NFS 客戶端：

$ sudo apt-get update
$ sudo apt-get install nfs-common

此時，您可以進行測試以檢查您是否可以從工作節點訪問您的共享：

$ sudo mkdir -p /mnt/sharedfolder_client
$ sudo mount kubemaster:/mnt/nfs_server_files /mnt/sharedfolder_client

請注意，此時您可以使用主節點的名稱。K8s 在這里處理 DNS。檢查卷是否按預期安裝，並為男性創建一些文件夾和文件，確保一切正常。

$ cd /mnt/sharedfolder_client
$ mkdir test
$ touch file

返回您的主節點並檢查這些文件是否位於 /mnt/nfs_server_files 文件夾中。

3 - 安裝 NFS 客戶端配置。

使用 helm 安裝配置器：

$ helm install --name ext --namespace nfs --set nfs.server=kubemaster --set nfs.path=/mnt/nfs_server_files stable/nfs-client-provisioner

請注意，我已經為它指定了一個命名空間。檢查它們是否正在執行：

$ kubectl get pods -n nfs
NAME                                         READY   STATUS      RESTARTS   AGE
ext-nfs-client-provisioner-f8964b44c-2876n   1/1     Running     0          84s

此時我們有一個名為 nfs-client 的儲存類：

$ kubectl get storageclass -n nfs
NAME         PROVISIONER                                AGE
nfs-client   cluster.local/ext-nfs-client-provisioner   5m30s

我們需要創建一個 PersistentVolumeClaim：

$ more nfs-client-pvc.yaml

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 namespace: nfs 
 name: test-claim
 annotations:
   volume.beta.kubernetes.io/storage-class: "nfs-client"
spec:
 accessModes:
   - ReadWriteMany
 resources:
   requests:
     storage: 1Mi

$ kubectl apply -f nfs-client-pvc.yaml

檢查狀態（預計綁定）：

$ kubectl get persistentvolumeclaim/test-claim -n nfs
NAME         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
test-claim   Bound    pvc-e1cd4c78-7c7c-4280-b1e0-41c0473652d5   1Mi        RWX            nfs-client     24s

4 - 創建一個簡單的 pod 來測試我們是否可以讀/寫 NFS 共享：

使用這個 yaml 創建一個 pod：

apiVersion: v1
kind: Pod
metadata:
 name: pod0
 labels:
   env: test
 namespace: nfs  
spec:
 containers:
 - name: nginx
   image: nginx
   imagePullPolicy: IfNotPresent
   volumeMounts:
     - name: nfs-pvc
       mountPath: "/mnt"
 volumes:
   - name: nfs-pvc
     persistentVolumeClaim:
       claimName: test-claim

$ kubectl apply -f pod.yaml

現在，讓我們深入這個 pod：

$ kubectl exec -ti -n nfs pod0 -- bash

讓我們列出我們 pod 上所有已安裝的捲：

root@pod0:/# df -h
Filesystem                                                                                Size  Used Avail Use% Mounted on
overlay                                                                                   9.8G  6.1G  3.3G  66% /
tmpfs                                                                                      64M     0   64M   0% /dev
tmpfs                                                                                     7.4G     0  7.4G   0% /sys/fs/cgroup
kubemaster:/mnt/nfs_server_files/nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12  9.8G  5.8G  3.6G  62% /mnt
/dev/sda1                                                                                 9.8G  6.1G  3.3G  66% /etc/hosts
shm                                                                                        64M     0   64M   0% /dev/shm
tmpfs                                                                                     7.4G   12K  7.4G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                                                                                     7.4G     0  7.4G   0% /proc/acpi
tmpfs                                                                                     7.4G     0  7.4G   0% /sys/firmware

正如我們所見，我們在 /mnt 上掛載了一個 NFS 卷。（重要的是要注意路徑kubemaster:/mnt/nfs_server_files/nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12）

讓我們檢查一下：

root@pod0:/# cd /mnt
root@pod0:/mnt# ls -la
total 8
drwxrwxrwx 2 nobody nogroup 4096 Nov  5 08:33 .
drwxr-xr-x 1 root   root    4096 Nov  5 08:38 ..

它是空的。讓我們創建一些文件：

$ for i in 1 2 4 5 6; do touch file$i; done;
$ ls -l 
total 8
drwxrwxrwx 2 nobody nogroup 4096 Nov  5 08:58 .
drwxr-xr-x 1 root   root    4096 Nov  5 08:38 ..
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file1
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file2
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file4
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file5
-rw-r--r-- 1 nobody nogroup    0 Nov  5 08:58 file6

現在讓我們看看這些文件在 NFS 伺服器（主節點）上的位置：

$ cd /mnt/nfs_server_files
$ ls -l 
total 4
drwxrwxrwx 2 nobody nogroup 4096 Nov  5 09:11 nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12
$ cd nfs-test-claim-pvc-4550f9f0-694d-46c9-9e4c-7172a3a64b12/
$ ls -l 
total 0
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file1
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file2
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file4
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file5
-rw-r--r-- 1 nobody nogroup 0 Nov  5 09:11 file6

這是我們剛剛在 pod 中創建的文件！

引用自：https://serverfault.com/questions/990520

相關問答

Storage

為什麼選擇 NAS 而不是“正常”的 NFS 共享？

  • May 18, 2021
檢視問答
Storage

Kubernetes 節點上的 NFS 伺服器？

  • April 26, 2021
檢視問答
Storage

NAS 在中高端儲存陣列上的案例是什麼？

  • September 2, 2015
檢視問答
Storage

使用商品硬體、開源軟體統一儲存的建議

  • September 24, 2010
檢視問答
Storage

將多個 NFS 導出掛載到同一個客戶端目錄

  • January 31, 2022
檢視問答
Permissions

如何在具有非 root 使用者權限的 Kubernetes pod 中掛載 azurefile persistentVolume？

  • November 2, 2021
檢視問答