【云原生】Kubernetes----PersistentVolume（PV）與PersistentVolumeClaim（PVC）詳解

引言

一、存儲卷

（一）存儲卷定義

（二）存儲卷的作用

1.數據持久化

2.數據共享

3.解耦

4.靈活性

（三）存儲卷的分類

1.emptyDir存儲卷

1.1 定義

1.2 特點

1.3 示例

2.hostPath存儲卷

2.1 定義

2.2 特點

2.3 示例

3.nfs存儲卷

3.1 定義

3.2 特點

3.3 示例

二、PV與PVC

（一）PV與PVC的定義

1.PV

2.PVC

（二）PV與PVC的關系

（三）實現過程

（四）靜態PV

1.建立共享目錄

2.定義PV

2.1 查看定義字段

2.3 創建PV

3.定義PVC

3.1 查看定義字段

3.2 創建PVC

4.創建pod

（五）動態PV

1.動態pv的定義

1.1 StorageClass

1.2 Provisioner

1.3 NFS-CLIENT-PROVISIONER

2.動態PV的作用

3.動態PV的使用流程

4.實現動態PV

4.1 創建共享目錄

4.2 部署NFS-CLIENT-PROVISIONER

4.3?創建Service Account

4.4 創建集群角色并綁定

4.4.1 創建clusterole

4.4.2 集群角色綁定

5.創建NFS Provisioner

5.1 基本介紹

5.2 創建

6. 創建StorageClass

7.創建PVC

7.1 關閉自鏈接

7.2 創建PVC

8.創建Pod

總結

引言

在Kubernetes（K8s）中，持久化存儲是一個至關重要的概念，它確保了在Pod重啟或遷移時數據不會丟失。為了實現這一目標，Kubernetes引入了PersistentVolume（PV）和PersistentVolumeClaim（PVC）這兩個資源對象。本文將詳細介紹PV和PVC的概念、工作原理以及它們之間的交互方式。

一、存儲卷

在介紹PV與PVC之前，首先了解一下什么是存儲卷

（一）存儲卷定義

存儲卷是Kubernetes中的一個重要概念，它為容器提供了持久化存儲或其他類型的存儲的能力。Pod中的容器可以通過存儲卷來訪問文件系統，存儲數據。存儲卷的類型有很多，如emptyDir、hostPath、NFS等。這些存儲卷類型都有其特定的用途和限制

（二）存儲卷的作用

1.數據持久化

當Pod中的容器因為各種原因（如升級、故障等）被銷毀或重啟時，存儲在容器內的數據通常會丟失。通過使用存儲卷，可以將數據存儲在Pod生命周期之外的位置，確保數據即使在容器或Pod重啟后仍然可用。

2.數據共享

存儲卷允許多個容器在Pod內部共享數據。這對于需要共享配置、日志或其他數據的容器來說非常有用。通過掛載相同的存儲卷，不同的容器可以訪問并修改其中的數據。

3.解耦

通過將數據存儲在存儲卷中，而不是直接存儲在容器內部，可以實現應用與數據之間的解耦。這意味著應用的代碼和數據可以分開管理，從而簡化應用的部署、升級和備份過程。

4.靈活性

Kubernetes支持多種類型的存儲卷，包括emptyDir、hostPath、NFS等。這為用戶提供了很大的靈活性，可以根據應用的需求選擇最適合的存儲解決方案。

還有一些其它的特性，如：

安全性：通過使用只讀存儲卷，可以限制容器對數據的修改權限，從而提高數據的安全性。此外，一些存儲卷類型（如加密云存儲）還可以提供額外的數據保護功能。

可移植性：存儲卷的使用使得應用在不同Kubernetes集群之間的遷移變得更加容易。只要目標集群支持相同的存儲卷類型，并且已經配置了相應的存儲資源，就可以輕松地將應用及其數據遷移到新的環境中。

日志和監控：存儲卷可以用于存儲應用的日志和監控數據。通過將日志和監控數據寫入存儲卷中，可以長期保存這些數據，并使用專門的日志和監控工具進行分析和警報。

（三）存儲卷的分類

1.emptyDir存儲卷

1.1 定義

emptyDir是Kubernetes中一種最簡單的存儲卷類型，其生命周期與Pod相同。當Pod被分配給某個節點時，會為該Pod創建一個emptyDir卷，并且只要Pod在該節點上運行，卷就一直存在。一旦Pod被刪除，emptyDir卷中的數據也會被永久刪除

1.2 特點

生命周期：emptyDir的生命周期與Pod相同，即當Pod被刪除時，emptyDir也會被刪除。

用途：emptyDir常用于臨時數據，如緩存空間、基于磁盤的歸并排序等。實現容器與容器之間數據共享

存儲位置：emptyDir存儲卷位于Pod所在節點的本地文件系統中

1.3 示例

在yaml文件中定義emptyDir存儲卷屬性

[root@master01 data]#vim  pod.yaml 
[root@master01 data]#cat  pod.yaml 
apiVersion: v1                       #指定Kubernetes API 的版本
kind: Pod                            #指定創建的資源類型為Pod
metadata:                            #定義pod元信息name: pod-nginx                    #指定pod的名稱
spec:                                #定義Pod的期望狀態。containers:                        #定義Pod中要運行的容器- name: nginx                      #指定容器名稱為nginximage: nginx:1.18.0              #指定鏡像imagePullPolicy: IfNotPresent    #指定鏡像拉取策略，優先使用本地鏡像，本地沒有則會拉取鏡像ports:                           #定義端口列表- name: http                     #指定端口名稱為httpcontainerPort: 80              #指定容器暴漏端口為80volumeMounts:                    #定義容器要掛載的卷- name: web                      #這是卷的名稱，與下面的volumes部分中定義的卷名稱相對應mountPath: /usr/shart/nginx/html #容器內部的掛載路徑應該是- name: centos                     #指定容器名稱centosimage: centos:7                  #指定鏡像imagePullPolicy: IfNotPresent    #指定鏡像拉取策略volumeMounts:                    #定義容器要掛載的卷- name: web                      #同樣定義卷的名稱，與volumes部分定義的名稱一致mountPath: /data/              #容器內部的掛載路徑command: ['/bin/sh','-c','while true;do echo $(date +%F--%H:%M:%S) >> /data/index.html;sleep 2;done']
#容器內部執行的命令，使用死循環語句，每兩秒輸出時間格式為%F(年、月、日)--%H(時):%M(分):%S(秒)到掛載的文件volumes:                           #定義了 Pod 中的卷- name: web                        #卷的名稱，與上面的volumeMounts部分中定義的名稱相對應emptyDir: {}                     #這定義了一個空目錄卷。Pod 中的所有容器都可以訪問這個卷
#當Pod被刪除時，這個卷也會被刪除。空目錄卷通常用于臨時存儲，例如在Pod中的容器之間共享數據

注釋：上述yaml文件的最終效果為

最下方volumes定義了一個名為web的卷，類型為emptyDir。emptyDir是一個臨時卷，它的生命周期與Pod相同。當Pod被分配給節點時，會創建一個空的卷（emptyDir: {}），并且只要Pod運行在該節點上，卷就一直存在。如果Pod從節點上刪除（無論是由于某些錯誤還是正常的刪除操作），則卷中的數據也會被永久刪除。

nginx容器將web卷（emptyDir: {}）掛載到/usr/share/nginx/html路徑下。

centos容器將web卷（emptyDir: {}）掛載到/data/路徑下。

因此，當這個Pod被創建并運行后，兩個容器都可以訪問和修改web卷（emptyDir: {}）中的數據。這可以用于共享數據、配置文件、日志文件等。但是，由于emptyDir是臨時的，所以一旦Pod被刪除，這些數據也會丟失

[root@master01 data]#kubectl apply -f pod.yaml 
pod/pod-nginx created
[root@master01 data]#kubectl get pod -owide
NAME        READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
pod-nginx   2/2     Running   0          5s    10.244.1.180   node01   <none>           <none>
[root@master01 data]#curl 10.244.1.180
2024-05-28--13:20:55
2024-05-28--13:20:57
2024-05-28--13:20:59
2024-05-28--13:21:01
2024-05-28--13:21:03
......

進入centos容器查看掛載情況

刪除pod數據也就會隨之消失，使用副本控制器創建的pod也只會重新創建新的pod，數據并不會移交同步

2.hostPath存儲卷

2.1 定義

hostPath卷將主機節點文件系統中的文件或目錄掛載到Pod中。這使得容器可以訪問到宿主機上的文件或目錄，從而實現數據的持久化存儲。

2.2 特點

生命周期：hostPath卷的生命周期與節點一致，而不是與Pod一致。即使Pod被刪除，hostPath卷中的數據仍會保留在節點上。

用途：hostPath卷通常用于一些需要訪問宿主機文件系統的特殊場景，如運行一些需要訪問宿主機文件的守護進程。

限制：由于hostPath卷直接掛載到宿主機的文件系統上，因此它可能會受到宿主機文件系統的限制，例如磁盤空間、權限等

2.3 示例

[root@master01 data]#kubectl delete pod --all  #刪除所有容器

[root@master01 data]#vim pod-hostpath.yaml 
[root@master01 data]#cat pod-hostpath.yaml 
apiVersion: v1  
kind: Pod 
metadata:name: pod-hostpath
spec:containers:- name: nginximage: nginx:1.18.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80volumeMounts:                       #定義如何在容器內部掛載存儲卷- name: web                         #指定要掛載的存儲卷的名稱，volumes.name字段定義的名稱mountPath: /usr/share/nginx/html  #容器內部的目錄路徑，存儲卷將被掛載到這個路徑上readOnly: false                   #false表示容器可以讀寫該存儲卷volumes:                              #定義宿主機上的目錄文件為Pod中可用的存儲卷，- name: web                           #自定義存儲卷的名稱hostPath:                           #指定存儲卷類型為hostPath，path: /data/web/nginx/            #指定宿主機上可以掛載到pod中的目錄或文件type: DirectoryOrCreate           #指定hostPath的類型，DirectoryOrCreate表示不存時創建
--------------------------------------------------------------------------------------
'readOnly'
#如果設置為true，則容器以只讀方式掛載的存儲卷；如果設置為false或空值，則容器可以讀寫該存儲卷'hostPath'
#允許將主機上的文件系統目錄或文件掛載到Pod中'type 可設置的類型值'
#"" (默認)：不進行任何特殊處理。
#DirectoryOrCreate：如果指定路徑下的目錄不存在，則創建它。
#Directory：目錄必須存在。
#FileOrCreate：如果指定路徑下的文件不存在，則創建它。
#File：文件必須存在。
#Socket：UNIX套接字必須存在。
#CharDevice：字符設備必須存在。
#BlockDevice：塊設備必須存在

此pod在node02節點上創建，在node02節點查看文件

[root@node02 ~]#cd  /data/web/nginx/
[root@node02 nginx]#ls
[root@node02 nginx]#echo "this is hostpath" >index.html  
#創建訪問頁面，因為是將宿主機上的目錄掛載到pod上，會覆蓋掛載點(/usr/share/nginx/html)下的文件
[root@node02 nginx]#curl 10.244.2.195
this is hostpath

即使刪除pod，由于文件是在宿主機上，hostPath存儲卷模式下，不會刪除節點上的文件

[root@master01 data]#kubectl delete pod pod-hostpath 
pod "pod-hostpath" deleted-----------------------------------------------------------------------------
//node02節點查看
[root@node02 nginx]#ls
index.html
[root@node02 nginx]#cat  index.html 
this is hostpath

需要注意的是，當宿主機（即node節點）發生故障時，數據仍會丟失，且hostPath卷直接引用主機上的文件或目錄，因此它可能會暴露敏感數據或允許Pod執行不受限制的操作。在生產環境中，通常建議使用更安全的存儲解決方案，如持久卷（PersistentVolumes）或云提供商提供的存儲服務。

當pod生命周期結束后創建新的pod，只要是指定掛載此存儲卷，依然可以訪問到數據

hostPath會自動優先選擇合適的節點，如node02上有指定的掛載路徑，則不需要再去node01節點上創建，會自動選擇帶有指定掛載路徑的節點

3.nfs存儲卷

3.1 定義

NFS（Network File System）是一種基于TCP/IP傳輸的網絡文件系統協議。通過使用NFS協議，客戶機可以像訪問本地目錄一樣訪問遠程服務器中的共享資源。在Kubernetes中，NFS存儲卷允許Pod訪問NFS服務器上的共享目錄。

3.2 特點

網絡存儲：NFS存儲卷是一種網絡存儲解決方案，可以實現數據的跨節點共享和訪問。

持久性：NFS存儲卷的數據存儲在NFS服務器上，因此具有持久性。即使Pod被刪除或重新調度到其他節點，數據仍然保留在NFS服務器上。

多個客戶端訪問：NFS支持多個客戶端同時掛載和訪問同一個NFS服務器上的共享目錄。

配置和管理：NFS需要單獨配置和管理NFS服務器，包括安裝NFS軟件包、設置共享目錄、配置訪問權限等

3.3 示例

[root@master01 data]#kubectl delete pod --all  #刪除所有容器

首先，搭建NFS共享服務器，并指定共享目錄

//在nfs服務器上操作
[root@nfs ~]#mkdir -p /nfs/volumes
[root@nfs ~]#chmod -R 777 /nfs/volumes/
[root@nfs ~]#echo "this is nfs" >/nfs/volumes/index.html
#創建共享目錄，并添加權限，自定義訪問界面[root@nfs ~]#vim /etc/exports
[root@nfs ~]#cat /etc/exports
/nfs/volumes/ 192.168.83.0/24(rw,no_root_squash)
#添加共享目錄信息及權限到/etc/exports文件中進行共享[root@nfs ~]#systemctl start rpcbind
[root@nfs ~]#systemctl start nfs
#啟動共享服務
[root@nfs ~]#ss -natp |grep rpcbind  #RPC端口，遠程連接
LISTEN   0   128    *:111      *:*      users:(("rpcbind",pid=46682,fd=4),("systemd",pid=1,fd=34))
LISTEN   0   128   :::111     :::*      users:(("rpcbind",pid=46682,fd=11))
[root@nfs ~]#ss -natp |grep 2049     #NFS端口，提供服務
LISTEN     0      64           *:2049                     *:*                  
LISTEN     0      64          :::2049                    :::*//任意節點查看共享情況
[root@node01 ~]#showmount -e 192.168.83.60
Export list for 192.168.83.60:
/nfs/volumes/ 192.168.83.0/24

定義nfs存儲卷文件

[root@master01 data]#vim pod-nfs.yaml 
[root@master01 data]#cat pod-nfs.yaml 
apiVersion: v1  
kind: Pod 
metadata:name: pod-nfs
spec:containers:- name: nginximage: nginx:1.18.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80volumeMounts:- name: nfsvmountPath: /usr/share/nginx/htmlreadOnly: falsevolumes:- name: nfsvnfs:                        #指定使用nfs存儲卷path: /nfs/volumes        #指定nfs服務器的共享目錄server: 192.168.83.60     #指定掛載的nfs服務器，地址映射后，也可以寫主機名

創建pod后，訪問容器就可以訪問到自定義的web界面

[root@master01 data]#kubectl apply -f pod-nfs.yaml 
pod/pod-nfs created
[root@master01 data]#kubectl get pod -owide 
NAME      READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
pod-nfs   1/1     Running   0          4s    10.244.1.181   node01   <none>           <none>
[root@master01 data]#curl 10.244.1.181
this is nfs

同樣的，刪除pod后，重新創建，只要使用nfs掛載此文件，可以得到數據的持久化存儲。

但是容易發生單點故障，服務器宕機時所有客戶端無法訪問，多臺客戶端掛載在同一臺服務器上，管理維護較繁瑣

總結來說，emptyDir、hostPath和NFS是Kubernetes中三種不同的存儲卷類型，它們各自具有不同的特點和用途。

emptyDir適用于臨時數據和需要共享數據的Pod，

hostPath適用于需要訪問宿主機文件系統的特殊場景，

NFS則是一種網絡存儲解決方案，可以實現數據的跨節點共享和訪問

二、PV與PVC

在Kubernetes中，存儲卷（Volumes）是Pod中可以訪問的存儲的抽象，用于存儲數據。然而，隨著Kubernetes集群的復雜性和多租戶的需求增長，僅僅依賴Pod中的存儲卷定義已經不足以滿足所有存儲需求。為了解決這個問題，Kubernetes引入了PersistentVolume（PV）和PersistentVolumeClaim（PVC）的概念，它們為存儲資源提供了更高層次的管理和抽象

（一）PV與PVC的定義

1.PV

定義：PV（Persistent Volume）是對底層的共享存儲的一種抽象，它由管理員進行創建和配置。PV是與具體的底層共享存儲技術的實現方式相關的，例如Ceph、GlusterFS、NFS等，它們通過插件機制完成與共享存儲的對接，實現數據持久化存儲。

關鍵信息：PV作為對存儲資源的定義，主要涉及存儲能力（即存儲空間的大小）、訪問模式（如ReadWriteOnce、ReadOnlyMany、ReadWriteMany等）、存儲類型、回收策略以及后端存儲類型等關鍵信息的設置。

2.PVC

定義：PVC（Persistent Volume Claim）是用戶對存儲的一種聲明，它與Pod比較類似。Pod消耗的是節點資源，而PVC消耗的是PV資源。PVC可以請求特定的存儲空間和訪問模式，而不需要用戶關心底層的存儲實現細節。

關鍵信息：PVC主要涉及存儲空間請求、訪問模式、PV選擇條件和存儲類別等信息的設置。當PVC被創建時，Kubernetes會嘗試將其與滿足其要求的PV進行綁定。如果系統中存在一個DefaultStorageClass，那么在創建PVC的時候可以不指定storageClassName，系統會自動使用默認的存儲類型。

（二）PV與PVC的關系

在 Pod 中定義一個存儲卷（該存儲卷類型為 PVC），定義的時候直接指定大小，PVC 必須與對應的 PV 建立關系，PVC 會根據配置的定義去 PV 申請，而 PV 是由存儲空間創建出來的。PV 和 PVC 是 Kubernetes 抽象出來的一種存儲資源

簡單來說，類似于LVM邏輯卷，LVM邏輯卷是將磁盤整合建立卷組，而后根據卷組建立邏輯卷并指定使用空間的大小

而PV就是將共享服務器（例如NFS、CEPH等）進行劃分，建立一個或多個PV存儲卷，PVC指定掛載存儲卷的大小及訪問模式（讀、寫），掛載對應的PV卷，達到數據持久化存儲

一般來說，PV和PVC之間的相互作用需要遵循以下生命周期

Provisioning---> Binding---> Using---> Releasing ---> Recycling?

?

● Provisioning（創建）：即 PV 的創建，可以直接創建 PV（靜態方式），也可以使用 StorageClass 動態創建

● Binding（綁定）：將 PV 分配給 PVC

● Using（使用）：Pod 通?PVC使用該 Volume，并可以通過準入控制StorageProtection（1.9及以前版本為PVCProtection）阻止刪除正在使用的 PVC

● Releasing（釋放）：Pod 釋放 Volume 并刪除 PVC

● Reclaiming（回收）： PV，可以保留 PV 以便下次使用，也可以直接從云存儲中刪除

（三）實現過程

以NFS共享服務器為例

①首先在NFS服務器上建立共享目錄

②建立PV卷，定義PV卷的大小與訪問模式

③創建PVS請求，是PVC與PC之間建立聯系

④創建pod，指定需要使用的PVC

（四）靜態PV

靜態PV就是手動創建PV，然后等待PVC請求，建立連接

NFS使用PV與PVC

1.建立共享目錄

//nfs服務器上操作，創建共享目錄
[root@nfs ~]#mkdir -p /nfs/pv/pv{1..4}
[root@nfs ~]#ls /nfs/pv/
pv1  pv2  pv3  pv4
[root@nfs ~]#chmod -R 777 /nfs/pv///添加共享目錄
[root@nfs ~]#cat /etc/exports
/nfs/pv/pv1 192.168.83.0/24(rw,no_root_squash)
/nfs/pv/pv2 192.168.83.0/24(rw,no_root_squash)
/nfs/pv/pv3 192.168.83.0/24(rw,no_root_squash)
/nfs/pv/pv4 192.168.83.0/24(rw,no_root_squash)
[root@nfs ~]#exportfs -r
[root@nfs ~]#showmount -e
Export list for nfs:
/nfs/pv/pv4 192.168.83.0/24
/nfs/pv/pv3 192.168.83.0/24
/nfs/pv/pv2 192.168.83.0/24
/nfs/pv/pv1 192.168.83.0/24

2.定義PV

2.1 查看定義字段

使用kubectl explain查看pv的定義方式

[root@master01 data]#kubectl explain pv
KIND:     PersistentVolume
VERSION:  v1apiVersion	<string>    #設置為v1即可，通用版本kind	<string>            #設置PV卷，kind的值為：PersistentVolumemetadata	<Object>        #PV是集群級別的資源，可以跨namespace，所以不需要指定spec	<Object>            #定義PV的特性status	<Object>        #狀態，創建后自動生成，一般不需要配置

查看pv.spec可設置字段

[root@master01 data]#kubectl explain pv.spec
...
---------------------'accessModes ([string] 類型)'---------------------------
定義了卷的訪問模式。PV 可以被單個節點以某種方式訪問，或者被多個節點以某種方式訪問。
可能的值有：
ReadWriteOnce (RWO): 卷可以被單個節點以讀寫模式掛載。
ReadOnlyMany (ROX): 卷可以被多個節點以只讀模式掛載。
ReadWriteMany (RWX): 卷可以被多個節點以讀寫模式掛載。
#注意：nfs支持三種訪問模式，但是不是所有的存儲類型都支持所有的訪問模式。
#例如iSCSI不支持ReadWriteMany；HostPath不支持ReadOnlyMany和ReadWriteMany
-------------------------------------------------------------------------------------------------------------'capacity '--------------------------------
描述了 PV 的存儲容量。通常包含一個條目鍵為storage值為存儲容量大小，
如storage: 1Gi
---------------------------------------------------------------------------------------------------------------'nfs'------------------------------------
定義存儲卷類型為nfs，以下常用兩個字段
path: 定義掛載卷路徑
server: 定義服務器名稱
---------------------------------------------------------------------------------------------'persistentVolumeReclaimPolicy (string 類型)'---------------
當 PV 不再被 PVC 引用時（即 PVC 被刪除），此字段定義了 PV 的回收策略
Retain: 手動回收，保留 PV，需要管理員手動處理。
Recycle: 基本棄用，只有 NFS 和 HostPath 支持
Delete: 刪除與 PV 關聯的存儲資源。
-----------------------------------------------------------------------------------------------------------'storageClassName'----------------------------
自定義存儲類名稱，此配置用于綁定具有相同類別的PVC和PV
如果 PV 屬于某個 StorageClass，則該字段將包含 StorageClass 的名稱。
PVC 可以請求特定 StorageClass 的 PV。
-------------------------------------------------------------------------------------------------------'volumeMode (string 類型)'-------------------------
指定了卷的模式，可以是文件系統或塊設備。
Filesystem: PV 作為文件系統掛載到容器中。
Block: PV 作為原始塊設備掛載到容器中（通常用于數據庫等需要直接訪問塊設備的場景）。--------------------------'nodeAffinity (Object)'----------------------------
描述了 PV 對節點的親和性規則。
-----------------------------------------------------------------------------
......

2.3 創建PV

定義3個PV，分別定義掛載的路徑以及訪問模式，還有PV劃分的大小。

[root@master01 data]#vim pv.yaml
[root@master01 data]#cat pv.yaml
apiVersion: v1
kind: PersistentVolume                     #定義了資源的類型為PersistentVolume
metadata:name: pv01labels:name: pv01
spec:                                      #這是PV的規格描述nfs:                                     #指定了PV的后端存儲類型為NFSpath: /nfs/pv/pv1                      #NFS服務器上存儲卷的路徑server: 192.168.83.60                  #NFS服務器的IP地址accessModes: ["ReadWriteMany","ReadWriteOnce"]   #定義PV的訪問模式為兩種，RWX,RWOcapacity:                                        #定義PV容量storage: 1Gi                                   #指定PV存儲容量為1GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv02labels:name: pv02
spec:nfs:path: /nfs/pv/pv2server: 192.168.83.60accessModes: ["ReadWriteOnce"]            #定義PV的訪問模式為RWOcapacity:storage: 2Gi                            #指定PV存儲容量為2GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv03labels:name: pv03
spec:nfs:path: /nfs/pv/pv3server: 192.168.83.60accessModes: ["ReadWriteMany","ReadWriteOnce"] #定義PV的訪問模式為兩種RWX,RWOcapacity:storage: 2Gi                                 #指定PV存儲容量為2GiB
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv04labels:name: pv04
spec:nfs:path: /nfs/pv/pv4server: 192.168.83.60accessModes: ["ReadWriteMany","ReadWriteOnce"]   #定義PV的訪問模式為兩種RWX,RWOcapacity:storage: 3Gi                                   #指定PV存儲容量為3GiB

查看創建結果

[root@master01 data]#kubectl apply -f pv.yaml
persistentvolume/pv01 created
persistentvolume/pv02 created
persistentvolume/pv03 created
persistentvolume/pv04 created
[root@master01 data]#kubectl get pv
NAME   CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv01   1Gi        RWO,RWX        Retain           Available                                   6s
pv02   2Gi        RWO            Retain           Available                                   6s
pv03   2Gi        RWO,RWX        Retain           Available                                   6s
pv04   3Gi        RWO,RWX        Retain           Available                                   6s'可用大小'   '訪問模式'

3.定義PVC

3.1 查看定義字段

[root@master01 data]#kubectl explain pvc
......apiVersion: v1
kind: PersistentVolumeClaim
metadata
spec
status
.....#apiVersion、metadata、status字段與pv基本一致，kind字段設置為PersistentVolumeClaim

查看pvc.spec下的字段

[root@master01 data]#kubectl explain pvc.spec---------------------'accessModes ([string] 類型)'---------------------------
描述用戶應用對存儲資源的訪問權限
ReadWriteOnce (RWO): 卷可以被單個節點以讀寫模式掛載。
ReadOnlyMany (ROX): 卷可以被多個節點以只讀模式掛載。
ReadWriteMany (RWX): 卷可以被多個節點以讀寫模式掛載。
#注意：nfs支持三種訪問模式，但是不是所有的存儲類型都支持所有的訪問模式。
#例如iSCSI不支持ReadWriteMany；HostPath不支持ReadOnlyMany和ReadWriteMany
------------------------------------------------------------------------------------------------------------'volumeMode'--------------------------------
描述希望使用的 PV 存儲卷模式。
可以是文件系統 (Filesystem) 或裸格式的塊設備 (Block)。
--------------------------------------------------------------------------------------------------------'resources (Object)'----------------------------
描述對存儲資源的請求。定義申請資源的大小
目前僅支持設置 requests.storage，即對存儲空間的設置。
-----------------------------------------------------------------------------------------------------'storageClassName (string)'------------------------
定義存儲類名稱，此配置用于綁定具有相同類別的PVC和PV
如果有多個 PV 符合 PVC 的要求，Kubernetes 會基于 PVC 指定的StorageClass來選擇 PV
--------------------------------------------------------------------------------------------------------'selector (Object)'----------------------------
一個可選字段，用于更精細地選擇 PV。
可以通過 matchLabels 和 matchExpressions 來選擇具有特定標簽的 PV。
----------------------------------------------------------------------------

3.2 創建PVC

定義的spec關鍵字段（如存儲大小，訪問模式、存儲類型）需要與PV信息匹配

[root@master01 data]#vim pvc.yaml
[root@master01 data]#cat pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim          #指定資源類型為PersistentVolumeClaim，即PVC
metadata:name: pvc01
spec:accessModes: ["ReadWriteMany"]     #定義期望獲得的訪問模式為ReadWriteMany,即RWXresources:                         #描述 PVC 的資源需求requests:                        #列出PVC所請求的特定資源storage: 2Gi   #指定PVC所請求的存儲容量。指定為2Gi，那么就會匹配存儲容量為2Gi的PV

查看創建結果

PV 的狀態（STATUS）有以下 4 種
● Available（可用）：表示可用狀態，還未被任何 PVC 綁定
● Bound（已綁定）：表示 PV 已經綁定到 PVC
● Released（已釋放）：表示 PVC 被刪掉，但是資源尚未被集群回收
● Failed（失敗）：表示該 PV 的自動回收失敗

4.創建pod

定義創建pod的yaml文件，并定義pvc掛載存儲

[root@master01 data]#vim pod-pv.yaml 
[root@master01 data]#cat pod-pv.yaml 
apiVersion: v1
kind: Pod
metadata:name: pod-pvnamespace: default
spec:containers:- name: nginximage: nginx:1.18.0volumeMounts:- name: web                         #指定要掛載的存儲卷名稱，與volumes.name字段設置的一致mountPath: /usr/share/nginx/html  #將volumes字段設置的存儲卷掛載到該路徑下volumes:- name: web                         #定義存儲卷名稱persistentVolumeClaim:            #定義存儲卷是由PersistentVolumeClaim(PVC)提供claimName: pvc01                #指定PVC名稱的pvc01

創建pod

[root@master01 data]#kubectl apply -f pod-pv.yaml 
pod/pod-pv created
[root@master01 data]#kubectl get pod pod-pv -owide
NAME     READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
pod-pv   1/1     Running   0          13s   10.244.2.199   node02   <none>           <none>

在nfs服務器上創建訪問頁面

//NFS服務器操作
[root@nfs ~]#cd  /nfs/pv/pv3     #PVC綁定的路徑
[root@nfs pv3]#echo "this is pv3" >index.html

訪問pod就可以看到自定義的訪問界面

[root@master01 data]#curl 10.244.2.199
this is pv3

此時就可以實現存儲數據的持久化，哪怕pod意外中斷退出，或手動刪除以后，數據依舊會保存在啊NFS服務器上。但是，此時因為手動創建了四個PV，而且是PVC是指定已經存在的PV，并匹配對應的PV資源類型，如果面對龐大的PVC請求，且請求的資源類型與訪問模式不同，如果設置的是靜態PV，那么就需要手動創建一個個對應的請求，這是一個龐大的工作量，想要解決這個問題就需要設置動態PV

（五）動態PV

1.動態pv的定義

動態PV是在集群級別使用StorageClass和Provisioner來自動創建PV對象的方式

Kubernetes 本身支持的動態PV創建，但是不包括NFS，所以需要使用外部存儲卷插件分配PV。卷插件稱為 Provisioner（存儲分配器），NFS 使用的是 nfs-client，這個外部PV。

1.1 StorageClass

StorageClass為管理員提供了一種描述存儲“類”（Class）的方法。它允許管理員定義不同的存儲類別，每個類別可能會映射到不同的服務質量等級、備份策略或其他存儲相關的策略。

StorageClass為用戶屏蔽了后端存儲的細節，用戶只需指定StorageClass的名稱，而無需關心具體的存儲實現。

基于StorageClass，Kubernetes可以動態地為PersistentVolumeClaims（PVCs）創建PersistentVolumes（PVs），從而實現了動態的資源供應。

1.2 Provisioner

用于指定 Volume 插件的類型，包括內置插件（如 kubernetes.io/aws-ebs）和外部插件（如 exte卷插件會使用已經配置好的 NFS 服務器自動創建 rnal-storage 提供的 ceph.com/cephfs）

1.3 NFS-CLIENT-PROVISIONER

Kubernetes的外部存儲供應器（provisioner），依賴于NFS服務來動態地創建PV。因此，在部署NFS-CLIENT-PROVISIONER之前，需要確保NFS服務已經部署并正常運行

2.動態PV的作用

自動創建：通過StorageClass指定存儲的類型和配置，由Provisioner自動創建和管理PV對象。

無需手動配置：與靜態PV不同，動態PV不需要管理員手動配置和管理PV資源。

可擴展與動態分配：適用于可擴展的、動態分配的存儲資源，用戶只需聲明所需的存儲要求，無需關心具體的存儲配置和管理。

3.動態PV的使用流程

①管理員首先定義一個StorageClass，它描述了存儲類的屬性，如存儲類型、后端存儲參數（如NFS服務器的地址和路徑）、回收策略等。StorageClass中指定了Provisioner插件，該插件負責根據StorageClass的定義動態創建PV

②根據StorageClass中指定的Provisioner插件，管理員需要在Kubernetes集群中安裝并配置相應的插件

③用戶或應用開發者在Kubernetes集群中創建一個PVC，指定所需的存儲大小、訪問模式以及StorageClass的名稱

④Kubernetes系統監控PVC的創建，并查找與之匹配的StorageClass。一旦找到匹配的StorageClass，Kubernetes會觸發Provisioner插件根據StorageClass的定義動態創建一個PV。

⑤創建好的PV會自動與PVC進行綁定。這個綁定過程是基于PVC中的請求參數（如存儲大小和訪問模式）與PV的屬性進行匹配的

⑥當Pod創建時，它可以指定使用某個已綁定的PVC。Kubernetes會將PV掛載到Pod中，使得Pod中的應用可以訪問該PV上的數據。

4.實現動態PV

創建之前，清空之前的操作記錄

[root@master01 data]#kubectl delete pod --all
pod "pod-pv" deleted
[root@master01 data]#kubectl delete pvc --all
persistentvolumeclaim "pvc01" deleted
[root@master01 data]#kubectl delete pv --all
persistentvolume "pv01" deleted
persistentvolume "pv02" deleted
persistentvolume "pv03" deleted
persistentvolume "pv04" deleted
---------------------------------------------------------------------
#刪除時需要注意的是，首先刪除PVC，因為PV一旦被占用，則無法進行刪除，需要刪除PVC釋放PV資源

4.1 創建共享目錄

//NFS服務器操作
[root@nfs pv3]#mkdir /nfs/k8s
[root@nfs pv3]#chmod -R 777 /nfs/k8s/
[root@nfs pv3]#vim /etc/exports
[root@nfs pv3]#cat /etc/exports
/nfs/k8s 192.168.83.0/24(rw,no_root_squash,sync)
[root@nfs pv3]#exportfs -r     #刷新配置
[root@nfs pv3]#showmount -e    #驗證共享目錄是否共享成功
Export list for nfs:
/nfs/k8s 192.168.83.0/24

4.2 部署NFS-CLIENT-PROVISIONER

在所有node節點上部署NFS-CLIENT-PROVISIONER鏡像

從Docker倉庫或其他可信來源下載NFS-CLIENT-PROVISIONER的Docker鏡像。并確保每個節點上都有NFS服務

鏡像下載地址：external-storage/nfs-client at master · kubernetes-retired/external-storage · GitHub

鏡像包下載完畢后上傳到node節點服務器，并使用docker命令生成鏡像

//node01
[root@node01 opt]#ls nfs-client-provisioner.tar 
nfs-client-provisioner.tar
[root@node01 opt]#docker load -i nfs-client-provisioner.tar
8dfad2055603: Loading layer [==============================>]  4.284MB/4.284MB
a17ae64bae4f: Loading layer [==============================>]  2.066MB/2.066MB
bd01fa00617b: Loading layer [==============================>]  39.72MB/39.72MB
Loaded image: quay.io/external_storage/nfs-client-provisioner:latest//node02
[root@node02 opt]#ls nfs-client-provisioner.tar 
nfs-client-provisioner.tar
[root@node01 opt]#docker load -i nfs-client-provisioner.tar
8dfad2055603: Loading layer [==============================>]  4.284MB/4.284MB
a17ae64bae4f: Loading layer [==============================>]  2.066MB/2.066MB
bd01fa00617b: Loading layer [==============================>]  39.72MB/39.72MB
Loaded image: quay.io/external_storage/nfs-client-provisioner:latest

4.3?創建Service Account

ServiceAccount是Kubernetes中的一種特殊類型的用戶賬戶，用于為Pod中的進程提供身份驗證和權限控制。為NFS-CLIENT-PROVISIONER創建一個ServiceAccount，可以確保它具有在集群中執行其職責所需的必要權限

[root@master01 pv]#vim service-account.yaml
[root@master01 pv]#cat service-account.yaml
apiVersion: v1
kind: ServiceAccount     #指定資源類型為用戶
metadata:name: nfs-client       #指定用戶名稱
[root@master01 pv]#kubectl apply -f service-account.yaml 
serviceaccount/nfs-client created
[root@master01 pv]#kubectl get sa    #查看用戶
NAME         SECRETS   AGE
default      1         13d
nfs-client   1         13s

4.4 創建集群角色并綁定

ClusterRole定義了集群級別的權限集，而ClusterRoleBinding則將這些權限集綁定到特定的ServiceAccount或用戶。為NFS-CLIENT-PROVISIONER創建一個ClusterRole，并為其分配必要的權限（如監聽apiserver、獲取集群資源列表、創建和刪除PV等），然后通過ClusterRoleBinding將其綁定到之前創建的ServiceAccount上。

[root@master01 pv]#kubectl explain clusterrole
#查看定義字段

4.4.1 創建clusterole

創建ClusterRole并添加相應的權限

[root@master01 pv]#vim cluster.yaml
[root@master01 pv]#cat cluster.yaml 
apiVersion: rbac.authorization.k8s.io/v1     #這表示使用的是RBAC API的版本1
kind: ClusterRole                            #定義一個集群級別的角色
metadata: name: clusterrole-nfs        #ClusterRole的名稱，用于在Kubernetes集群中唯一標識
rules:                         #ClusterRole中定義的具體權限列表- apiGroups: [""]resources: ["persistentvolumes"]verbs: ["get", "list", "watch", "create", "delete"]
#第一個規則組
#apiGroups: [""]：表示核心API組，不包含任何前綴的API組
#resources: ["persistentvolumes"]：表示對持久卷（PersistentVolumes）的權限。
#verbs: 列出了可以執行的操作get(獲取)、list(列表)、watch(監聽)、create(創建)和delete(刪除)- apiGroups: [""]resources: ["persistentvolumeclaims"]verbs: ["get", "list", "watch", "update"]
#第二各規則組，與第一個規則類似，但針對的是持久卷聲明（PersistentVolumeClaims）- apiGroups: ["storage.k8s.io"]resources: ["storageclasses"]verbs: ["get", "list", "watch"]
#第三個規則組
#apiGroups: ["storage.k8s.io"]：這是存儲API組的名稱
#resources: ["storageclasses"]：表示對存儲類（StorageClasses）的權限。
#verbs: 列出了可以執行的操作，但僅允許讀取操作（get、list和watch）- apiGroups: [""]resources: ["events"]verbs: ["list", "watch", "create", "update", "patch"]
#定義了對Kubernetes事件（Events）的權限- apiGroups: [""]resources: ["endpoints"]verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
#定義了對端點（Endpoints）的廣泛權限，包括創建、刪除、獲取、列表、監聽、補丁和更新

[root@master01 pv]#kubectl apply -f cluster.yaml 
clusterrole.rbac.authorization.k8s.io/clusterrole-nfs created
[root@master01 pv]#kubectl get clusterroles clusterrole-nfs -owide
NAME              CREATED AT
clusterrole-nfs   2024-05-29T09:30:10Z

4.4.2 集群角色綁定

[root@master01 pv]#vim clusterbind.yaml 
[root@master01 pv]#cat clusterbind.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding                #資源類型為ClusterRoleBinding，集群級別的角色綁定
metadata:name: nfs-client-clusterrolebinding   #定義資源名稱
subjects:                               #定義了哪些用戶或用戶組會被授予權限
- kind: ServiceAccount                  #引用一個ServiceAccountname: nfs-client                      #ServiceAccount名稱為nfs-client，這是之前創建的用戶namespace: default                    #指定ServiceAccount所在命名空間
roleRef:                                #定義了該綁定所引用的ClusterRolekind: ClusterRole                     #正在引用一個ClusterRolename: clusterrole-nfs                 #ClusterRole的名稱，上一步創建的ClusterRole名稱apiGroup: rbac.authorization.k8s.io   #這是API組的名稱，對于ClusterRole，它通常是rbac.authorization.k8s.io

[root@master01 pv]#kubectl apply -f clusterbind.yaml 
clusterrolebinding.rbac.authorization.k8s.io/nfs-client-clusterrolebinding created
[root@master01 pv]#kubectl get clusterrolebindings nfs-client-clusterrolebinding  -owide
NAME                            ROLE                      AGE   USERS   GROUPS   SERVICEACCOUNTS
nfs-client-clusterrolebinding   ClusterRole/clusterrole   69s                    default/nfs-client-nfs

5.創建NFS Provisioner

5.1 基本介紹

NFS Provisioner是一個自動配置卷程序，本質上就是一個pod，其主要功能是利用現有的和已配置的NFS服務器來支持通過持久卷聲明動態配置Kubernetes持久卷

NFS Provisione(即 nfs-client)，有兩個功能：

①NFS Provisioner能夠自動為Kubernetes集群中的Pod提供NFS持久卷。，在 NFS 共享目錄下創建掛載點(volume)，持久卷的名稱遵循一定的格式，通常是namespace-{pvcName}-${pvName}。

②將 PV 與 NFS 的掛載點建立關聯。

它的工作原理

當Kubernetes集群中的Pod需要訪問NFS持久卷時，通過持久卷聲明（PersistentVolumeClaim）來請求。NFS Provisioner會監聽這些聲明，并自動創建和配置相應的NFS持久卷

5.2 創建

使用Deployment創建nfs-client-provisioner，防止因為它發生故障時退出，導致NFS服務器無法使用

[root@master01 pv]#cat nfs-client-pro.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nfs-client-provisioner
spec:replicas: 1selector:matchLabels:app: nfs-client-provisionerstrategy:                            #指定更新Pod的策略type: Recreate                     #更新Deployment時，將使用重建（Recreate）策略template:metadata:labels:app: nfs-client-provisionerspec:serviceAccountName: nfs-client   #指定Pod使用的ServiceAccount的名稱containers:- name: nfs-client-provisionerimage: quay.io/external_storage/nfs-client-provisioner:latest  #之前下載的鏡像imagePullPolicy: IfNotPresentvolumeMounts:                #定義容器內的掛載點，掛載到什么位置- name: nfs-k8s            #掛載卷名稱。volumes定義的mountPath: /persistentvolumes #掛載到該路徑env:                         #定義容器的環境變量。- name: PROVISIONER_NAME   #變量名稱，配置provisioner的Namevalue: nfs-storage       #變量值，此值在建立StorageClass時使用- name: NFS_SERVER         #變量名稱，指定NFS服務器value: 192.168.83.60     #NFS服務器地址或主機名- name: NFS_PATH           #變量名稱，指定共享目錄value: /nfs/k8s          #NFS共享目錄volumes:                         #定義Pod中的卷- name: nfs-k8s                #卷的名稱，與上面的volumeMounts定義中的名稱相匹配nfs:                         #定義NFS卷的參數server: 192.168.83.60      #NFS服務器的地址path: /nfs/k8s             #NFS服務器上的共享路徑-------------------------------------------------------------------------------
Recreate（重建）: 使用此策略時，Kubernetes會首先終止所有的舊Pods，然后等待這些Pods都被
完全刪除并清理后，再創建新的Pods。這意味著在更新過程中，服務可能會經歷一段不可用時間，因
為所有的Pods都會被同時替換。雖然這種方法可能導致服務中斷，但它有時更簡單、更可靠，特別是
當應用程序不支持滾動更新或者需要確保在更新過程中沒有兩個版本的Pods同時運行時。

[root@master01 pv]#kubectl apply -f nfs-client-pro.yaml 
deployment.apps/nfs-client-provisioner created
[root@master01 pv]#kubectl get deployments.apps nfs-client-provisioner 
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
nfs-client-provisioner   1/1     1            1           15s
[root@master01 pv]#kubectl get pod
NAME                                      READY   STATUS    RESTARTS   AGE
nfs-client-provisioner-544dbf9f94-f948s   1/1     Running   0          45s

6. 創建StorageClass

負責建立 PVC 并調用 NFS provisioner 進行預定的工作，并讓 PV 與 PVC 建立關聯

定義StorageClass：StorageClass是Kubernetes中用于描述存儲類的一種資源對象。通過定義StorageClass，可以指定如何為PVC提供后端存儲（如NFS）。

在StorageClass中，可以指定Provisioner（如NFS-CLIENT-PROVISIONER）、存儲類型、配置參數等。

StorageClass的作用：當PVC被創建時，Kubernetes會根據PVC的存儲要求查找匹配的StorageClass，并委托給相應的Provisioner來創建滿足要求的PV。因此，StorageClass是PVC和PV之間的橋梁，它使得Kubernetes能夠根據PVC的要求動態地創建和管理PV。

[root@master01 pv]#cat nfs-storageclass.yaml 
apiVersion: storage.k8s.io/v1     #指定了Kubernetes API的版本和組
kind: StorageClass                #創建StorageClass資源
metadata:name: nfs-client-storageclass   #指定名稱
provisioner: nfs-storage          
#指定了用于供應存儲卷的供應器（provisioner）的名稱
#與創建nfs-client-provisioner的PROVISIONER_NAME變量的值相同
parameters:                       #供應器需要的任何額外參數archiveOnDelete: "false"        #false表示在刪除PVC時不會對數據進行存檔，即刪除數據

PROVISIONER：這是負責為PersistentVolumeClaims（PVCs）動態創建PersistentVolumes（PVs）的存儲系統

RECLAIMPOLICY：定義了當PersistentVolume（PV）的聲明（PVC）被刪除時，PV應該怎么做。Delete策略意味著PV和它上面的數據將被刪除。

VOLUMEBINDINGMODE：定義了如何以及何時將PersistentVolumeClaims（PVCs）綁定到PersistentVolumes（PVs）。Immediate模式意味著一旦PVC被創建，就會立即查找并綁定一個合適的PV。

ALLOWVOLUMEEXPANSION：定義了是否允許擴展已存在的PersistentVolume（PV）。設置為false表示不允許擴展。

7.創建PVC

7.1 關閉自鏈接

在創建PVC之前，首先需要修改以下APIserver的參數

vim?/etc/kubernetes/manifests/kube-apiserver.yaml
.......
spec:
? containers:
? - command:
? ? - kube-apiserver
? ??- --feature-gates=RemoveSelfLink=false ? ? ? #添加此字段

此字段用于關閉自鏈接（self-link）功能

在Kubernetes 1.20及更高版本中，由于API的更改，許多組件不再使用或提供自鏈接字段。當NFS Provisioner嘗試訪問PVC（Persistent Volume Claim）的自鏈接以創建PV時，可能會因為找不到該字段而報錯。

報錯示例：

報錯信息可能類似于“unexpected error getting claim reference: selfLink was empty, can't make reference”。

這表明Provisioner試圖獲取PVC的自鏈接，但發現它是空的

[root@master01 data]#kubectl apply -f /etc/kubernetes/manifests/kube-apiserver.yaml 
pod/kube-apiserver created
#更新apiserver
[root@master01 data]#kubectl get pod -n kube-system  |grep apiserver
kube-apiserver                     0/1     CrashLoopBackOff   1          19s
kube-apiserver-master01            1/1     Running            0          99s
[root@master01 data]#kubectl delete pod kube-apiserver -n kube-system 
pod "kube-apiserver" deleted
#刪除之前的kube-apiserver

7.2 創建PVC

[root@master01 pv]#vim  pvc.yaml 
[root@master01 pv]#cat  pvc.yaml 
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: pvc-nfs
spec:accessModes: ["ReadWriteMany"]storageClassName: nfs-client-storageclass   #指定關聯StorageClass對象名稱resources:requests:storage: 2Gi

PVC 通過 StorageClass 自動申請到空間

如果Provisioner沒有創建PV，那么它的日志中可能包含有關為什么無法創建PV的詳細信息。使用kubectl logs <nfs-provisioner-pod-name> -n <namespace>來獲取日志

創建完pvc后，會在NFS服務器的共享目錄中建立一個文件

[root@nfs nfs]#ls  /nfs/k8s/
default-pvc-nfs-pvc-e2f92c4e-a04c-4243-a131-566c0103717e
#自動創建的PV會以${namespace}-${pvcName}-${pvName}的目錄格式放到NFS服務器上

8.創建Pod

[root@master01 pv]#vim pod.yaml
[root@master01 pv]#cat pod.yaml
apiVersion: v1
kind: Pod
metadata:name: nginx-pod
spec:containers:- name: nginximage: nginx:1.18.0volumeMounts:- name: nfs-pvcmountPath: /usr/share/nginx/htmlvolumes:- name: nfs-pvcpersistentVolumeClaim:     #使用PersistentVolumeClaim作為卷源claimName: pvc-nfs       #引用之前創建的PersistentVolumeClaim的名稱

在NFS服務器的PV目錄上自定義一個web訪問界面