目錄
前言
一、Volume 的概念
二、Volume 的類型
常見的卷類型
Kubernetes 獨有的卷類型
三、通過 emptyDir 共享數據
1. 編寫 emptyDir 的 Deployment 文件
2. 部署該 Deployment
3. 查看部署結果
4. 登錄 Pod 中的第一個容器
5. 登錄 Pod 中的第二個容器查看/mnt下的文件
6. 刪除此 Pod
四、使用 HostPath 掛載宿主機文件
1. 編寫 Deployment 文件，實現 HostPath 掛載
2. 創建此 Pod
3. 查看創建結果
4. 測試掛載情況
5. 刪除
五、掛載 NFS 至容器
1. 安裝 NFS
2. 設置共享目錄（在 NFS 服務器上）
3. 開啟 nfs（在 NFS 服務器上）
4. 編寫 Deployment 文件，掛載 NFS
5. 部署此 Pod
6. 查看部署結果
7. 登錄容器查看掛載結果
六、PersistentVolume（PV，持久卷）
1. PV 回收策略
2. PV 訪問策略
3. PV 的配置方式
（1）靜態配置
（2）動態配置
4. 基于 HostPath 的 PV
5. 基于 NFS 的 PV
七、PersistentVolumeClaim（PVC，持久卷聲明）
1. PVC 的創建
2. PVC 的使用
前言
數據是企業發展的核心，尤其在生產環境中，數據的存儲和管理顯得尤為重要。Kubernetes 作為容器編排領域的佼佼者，在數據存儲方面也提供了強大的支持。本筆記將詳細介紹 Kubernetes 存儲相關知識，包括 Volume 的概念、類型及使用方法，以及 PersistentVolume 和 PersistentVolumeClaim 的相關內容，幫助讀者掌握 Kubernetes 中存儲的基本概念和操作方法，為在生產環境中構建高效、可擴展的存儲解決方案打下堅實的基礎。
一、Volume 的概念
對于大多數項目而言，數據文件的存儲是非常常見的需求，比如存儲用戶上傳的頭像、文件以及數據庫的數據。在 Kubernetes 中，由于應用的部署具有高度的可擴展性和編排能力（不像傳統架構部署在固定的位置），因此把數據存放在容器中是非常不可取的，這樣無法保障數據的安全。
我們應該把有狀態的應用變成無狀態的應用，即把數據從應用中剝離出來，將產生的數據文件或者緩存的信息放在云端，比如常用的 NFS（生產環境中不建議使用，因為存在單點故障，推薦使用分布式的存儲或者公有云的 NAS 服務）、Ceph、GlusterFS、Minio 等。
在傳統架構中，如果要使用這些存儲，需要提前在宿主機掛載，然后程序才能訪問，實際使用時，經常會碰到新加節點忘記掛載存儲導致的一系列問題。而 Kubernetes 在設計之初就考慮了這些問題，并抽象出 Volume 的概念用于解決數據存儲的問題。
容器中的磁盤文件是短暫的，當容器崩潰時，Kubectl 會重新啟動容器，但容器運行時產生的數據文件都會丟失，之后容器會以干凈的狀態啟動。另外，當一個 Pod 運行多個容器時，各個容器可能需要共享一些文件，諸如此類的需求都可以使用 Volume 解決。
Docker 也有卷的概念，但在 Docker 中，卷只是磁盤上或另一個容器中的目錄，其生命周期不受管理。雖然 Docker 已經提供了卷驅動程序，但功能非常有限，例如從 Docker1.7 版本開始，每個容器只允許一個卷驅動程序，并且無法將一些特殊的參數傳遞給后端存儲。
另一方面，Kubernetes 卷具有明確的生命周期，與使用它的 Pod 相同，因此在 Kubernetes 中的卷可以比 Pod 中運行的任何容器的生命周期都長，并且可以在容器重啟或者銷毀之后保留數據。Kubernetes 支持多種類型的卷，并且 Pod 可以同時使用任意數量的卷。
從本質上講，和虛擬機或者物理機一樣，卷被掛載后，在容器中也只是一個目錄，可能包含一些數據，Pod 中的容器也可以對其進行增刪改查操作，使用方式和裸機掛載幾乎沒有區別。要使用卷也非常簡單，和其他參數類似，Pod 只需要通過.spec.volumes字段指定為 Pod 提供的卷，然后在容器中配置塊，使用.spec.containers.volumeMounts字段指定卷的掛載目錄即可。
二、Volume 的類型
在傳統架構中，企業內可能有自己的存儲平臺，比如 NFS、Ceph、GlusterFS、Minio 等。如果所在的環境在公有云，也可以使用公有云提供的 NAS、對象存儲等。在 Kubernetes 中，Volume 也支持配置這些存儲，用于掛載到 Pod 中實現數據的持久化。Kubernetes Volume 支持的卷的類型有很多。
常見的卷類型
- CephFS
- GlusterFS
- ISCSI
- Cinder
- NFS
- RBD
- HostPath
Kubernetes 獨有的卷類型
- ConfigMap：用于存儲配置文件
- Secret：用于存儲敏感數據
- EmptyDir：用于一個 Pod 內多個容器的數據共享
- PersistentVolumeClaim：對 PersistentVolume 的申請
三、通過 emptyDir 共享數據
emptyDir 是一個特殊的 Volume 類型，與上述 Volume 不同的是，如果刪除 Pod，EmptyDir 卷中的數據也將被刪除，所以一般 emptyDir 用于 Pod 中不同容器共享數據，比如一個 Pod 存在兩個容器 A 和容器 B，容器 A 需要使用容器 B 產生的數據，此時可以采用 emptyDir 共享數據，類似的使用如 Filebeat 收集容器內程序產生的日志。
使用 emptyDir 卷時，直接指定 emptyDir 為{}即可。
1. 編寫 emptyDir 的 Deployment 文件
[root@k8s-master ~]#cat <<EOF>nginx-empty.yaml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: nginxnamespace: default
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginx01volumeMounts:- mountPath: /optname: share-volume- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginx02command:- sh- -c- sleep 3600volumeMounts:- mountPath: /mntname: share-volumevolumes:- name: share-volumeemptyDir: {}#medium: Memory
EOF
備注：
volumeMounts:mountPath: /mnt name: share-volume：容器定義部分的卷掛載名稱，此處的名稱引用了 volumes 對應的名稱
volumes:name: share-volume：共享存儲卷的名稱
此案例會將 nginx01 中/opt中的數據，共享給 nginx02 中的/mnt目錄。
此部署文件創建一個 Deployment，采用spec.volume字段配置了一個名字為share-volume、類型為emptyDir的 volume，同時里面包含兩個容器nginx01和nginx02，并將該 volume 掛載到了/opt和/mnt目錄下，此時/opt和/mnt目錄的數據就實現了共享。
默認情況下，emptyDir 支持節點上的任何介質，可以是 SSD、磁盤或是網絡存儲，具體取決于自身環境。可以將emptyDir.medium字段設置為Memory，讓 Kubernetes 使用tmpfs（內存支持的文件系統），雖然tmpfs非常快，但是在節點重啟時，數據同樣會被清除，并且設置的大小會被記入 Container 的內存限制中。
2. 部署該 Deployment
[root@k8s-master ~]#kubectl create -f nginx-empty.yaml
3. 查看部署結果
[root@k8s-master ~]#kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-6fffbd7c7b-jrw7f 2/2 Running 0 10s
4. 登錄 Pod 中的第一個容器
[root@k8s-master~]#kubectl exec -ti nginx-6fffbd7c7b-jrw7f -c nginx01 -- sh
備注：在該容器中的/opt下創建一個文件，并到第二個容器中查看，是否是共享的目錄。
5. 登錄 Pod 中的第二個容器查看/mnt下的文件
[root@k8s-master~]#kubectl exec -ti nginx-6fffbd7c7b-jrw7f -c nginx02 -- sh
注意：登錄后，此處可以使用date命令查看容器中的時間，會發現時間是不對的。是因為時區的問題，容器內使用的不是亞洲上海市區，導致時間不對。
6. 刪除此 Pod
[root@k8s-master ~]#kubectl delete -f nginx-empty.yaml
四、使用 HostPath 掛載宿主機文件
HostPath 卷可以將節點上的文件或目錄掛載到 Pod 上，用于實現 Pod 和宿主機之間的數據共享，常用的示例有掛載宿主機的時區至 Pod，或者將 Pod 的日志文件掛載到宿主機等。
1. 編寫 Deployment 文件，實現 HostPath 掛載
以下為使用 HostPath 卷的示例，實現將主機的/etc/localtime文件掛載到 Pod 的/etc/localtime：
[root@k8s-master ~]#cat<<EOF nginx-hostPath.yaml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: nginxnamespace: default
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginxvolumeMounts:- mountPath: /etc/localtimename: timezone-timevolumes:- name: timezone-timehostPath:path: /etc/localtimetype: File
EOF
備注：關于時區的設置是通過配置/etc/localtime文件設置系統的時區，/etc/localtime用于配置系統時區（此文件是一個鏈接文件，鏈接自/usr/share/zoneinfo/Asia/Shanghai）。
2. 創建此 Pod
[root@k8s-master ~]#kubectl create -f nginx-hostPath.yaml
3. 查看創建結果
[root@k8s-master ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-5c9b77966c-jrw7f 1/1 Running 0 47m
4. 測試掛載情況
[root@k8s-master~]#kubectl exec -ti nginx-5c9b77966c-jrw7f - nginx --sh
#date
在配置 HostPath 時，有一個type參數，用于表達不同的掛載類型，HostPath 卷常用的類型有：
type為空字符串：默認選項，在掛載 HostPath 卷之前不會有任何檢查DirectoryOrCreate：如果給定的 path 不存在任何東西，那么將根據需要創建一個權限為 0755 的空目錄，和 kubelet 具有相同的組和權限Directory：目錄必須存在于給定的路徑下FileOrCreate：如果給定的路徑不存在任何內容，則會根據需要創建一個空文件，權限設置為 0644，和 kubelet 具有相同的組和所有權File：文件，必須存在于給定的路徑中Socket：UNIX 套接字，必須存在于給定的路徑中CharDevice：字符設備，必須存在于給定的路徑中BlockDevice：塊設備，必須存在于給定的路徑中
5. 刪除
[root@k8s-master ~]#kubectl delete -f nginx-hostPath.yaml
五、掛載 NFS 至容器
1. 安裝 NFS
在所有的 Kubernetes 節點都要安裝：
[root@k8s-master ~]#yum -y install nfs-utils
2. 設置共享目錄（在 NFS 服務器上）
[root@k8s-master~]#mkdir /opt/wwwroot
[root@k8s-master~]#echo "This is my test file" > /opt/wwwroot/index.html
[root@k8s-master ~]#vim /etc/exports
/opt/wwwroot 192.168.10.0/24(rw,sync,no_root_squash)
3. 開啟 nfs（在 NFS 服務器上）
[root@k8s-master ~]#systemctl start nfs
[root@k8s-master ~]#systemctl start rpcbind
4. 編寫 Deployment 文件，掛載 NFS
[root@k8s-master ~]#cat<<EOF nginx-nfsvolume.yaml
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: nginxnamespace: default
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- image: nginx:1.7.9imagePullPolicy: IfNotPresentname: nginxvolumeMounts:- mountPath: /usr/share/nginx/htmlname: nfs-volumevolumes:- name: nfs-volumenfs:server: 192.168.10.101path: /opt/wwwroot
EOF
5. 部署此 Pod
[root@k8s-master~]#kubectl create -f nginx-nfsvolume.yaml
6. 查看部署結果
[root@k8s-master ~]#kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx-fbd476c4c-zscq9 1/1 Running 0 8m12s
7. 登錄容器查看掛載結果
[root@k8s-master~]#kubectl exec -ti nginx-fbd476c4c-zscq9 - nginx --bash
六、PersistentVolume（PV，持久卷）
雖然 volume 已經可以接入大部分存儲后端，但是實際使用時還有諸多的問題。比如：
- 當某個數據卷不再被掛載使用時，里面的數據如何處理？
- 如果想要實現只讀掛載，要如何處理？
- 如果想要只能有一個 Pod 掛載，要如何處理？
如上所述，對于很多復雜的需求，volume 可能難以實現，并且無法對存儲的生命周期進行管理。另一個很大的問題是，在企業內使用 kubernetes 的不僅僅是 kubernetes 管理員，可能還有開發人員、測試人員以及初學 kubernetes 的技術人員，對于 kubernetes 的 volume 或者相關存儲平臺的配置參數并不了解，所以無法自行完成存儲的配置。
為此，kubernetes 引入了兩個新的 API 資源：PersistentVolume（持久卷，簡稱 PV）和 PersistentVolumeClaim（持久卷聲明，簡稱 PVC）。
PV 是 kubernetes 管理員設置的存儲，PVC 是對 PV 的請求，標識需要什么類型的 PV。他們同樣是集群中的一類資源，但其生命周期比較獨立，管理員可以單獨對 PV 進行增刪改查，不受 Pod 的影響，生命周期可能比掛載它的其他資源還要長。如果一個 kubernetes 集群的使用者并非只有 kubernetes 管理員，那么可以通過提前創建 PV，用以解決對存儲概念不是很了解的技術人員對存儲的需求。和單獨配置 volume 類似，PV 也可以使用 NFS、GFS、CEPH 等常見的存儲后端，并且可以提供更為高級的配置，比如訪問模式、空間大小以及回收策略等。目前 PV 的提供方式有兩種：靜態或動態。靜態 PV 由管理員提前創建，動態 PV 無需提前創建。
1. PV 回收策略
當用戶使用完卷時，可以從 API 中刪除 PVC 對象，從而允許回收資源。回收策略會告訴 PV 如何處理該卷。目前回收策略可以設置為 Retain、Recycle 和 Delete。靜態 PV 默認的為 Retain，動態 PV 默認為 Delete。
Retain：保留，該策略允許手動回收資源，當刪除 PVC 時，PV 仍然存在，PV 中的數據也存在。volume 被視為已釋放，管理員可以手動回收卷。Recycle：回收，如果 volume 插件支持，Recycle 策略會對卷執行rm -rf清理該 PV，卷中的數據已經沒了，但卷還在，使其可用于下一個新的 PVC，但是本策略將會被棄用，目前只有 NFS 和 HostPath 支持該策略。Delete：刪除，如果 volume 插件支持，刪除 PVC 時會同時刪除 PV，PV 中的數據自然也就沒了。動態卷默認為 Delete，目前支持 Delete 的存儲后端包括 ANS EBS、GCE PD、Azure Disk、OpenStack Cinder 等。
2. PV 訪問策略
在實際使用 PV 時，可能針對不同的應用會有不同的訪問策略，比如某類 Pod 可以讀寫，某類 Pod 只能讀，或者需要配置是否可以被多個不同的 Pod 同時讀寫等，此時可以使用 PV 的訪問策略進行簡單控制，目前支持的訪問策略如下：
ReadWriteOnce：單路可讀可寫，可以被單節點以讀寫模式掛載，命令行中可以被縮寫為 RWO。ReadOnlyMany：多路只讀，可以被多節點以只讀模式掛載，命令行中可以被縮寫為 ROX。ReadWriteMany：多路可讀可寫，可以被多個節點以讀寫模式掛載，命令行中可以被縮寫為 RMX。ReadWriteOncePod：單節點只讀（1.22+），只能被一個 Pod 以讀寫的模式掛載，命令行中可以被縮寫為 RWOP。
雖然 PV 在創建時可以指定不同的訪問策略，但是也要后端的存儲支持才行。比如一般情況下，大部分塊存儲是不支持ReadWriteMany的。
在企業內，可能存儲很多不同類型的存儲，比如 NFS、Ceph、GlusterFS 等，針對不同類型的后端存儲具有不同的配置方式，這也是對集群管理員的一種挑戰，因為集群管理員需要對每種存儲都要有所了解。
3. PV 的配置方式
（1）靜態配置
靜態配置是手動創建 PV 并定義其屬性，例如容量、訪問模式、存儲后端等。在這種情況下，Kubernetes
第12章：Kubernetes存儲入門.pdf
接著上面的繼續
管理員負責管理和配置 PV，然后應用程序可以使用這些 PV。靜態配置通常用于一些固定的存儲后端，如 NFS。
（2）動態配置
動態配置允許 Kubernetes 集群根據 PVC 的需求自動創建 PV，在這種情況下，管理員只需為存儲后端配置 storageClass，然后應用程序就可以通過 PVC 請求存儲。Kubernetes 將自動創建與 PVC 匹配的 PV，并將其綁定到 PVC 上。這種方法使得存儲管理更加靈活和可擴展，允許管理員在集群中動態添加、刪除和管理存儲資源。
4. 基于 HostPath 的 PV
可以創建一個基于 HostPath 的 PV，和配置 NFS 的 PV 類似，只需要配置 hostPath 字段即可，其它配置基本一致。
（1）在所有 node 節點創建主機目錄
[root@k8s-master~]#mkdir /mnt/data
（2）編輯 hostpath 的 yaml 文件
[root@k8s-master~]#cat<<EOF>hostpath-pv.yaml
kind: PersistentVolume
apiVersion:v1
metadata:name:mypv-hostpathlabels:type:local
spec:storageClassName :pv-hostpathcapacity:storage:10GiaccessModes :- ReadWriteOncehostPath:path:"/mnt/data"
EOF
備注：
- hostPath: 宿主機的路徑，使用 hostPath 類型需要固定 Pod 所在的節點，防止 Pod 漂移造成數據丟失。
- storageClassName 是一個用于標識 StorageClass 對象名稱的標簽。當你創建或配置 PersistentVolumeClaim (PVC) 時，可以指定 storageClassName 來告訴 Kubernetes 你希望使用哪個 Storageclass 來配置存儲。
（3）創建并查看 PV
[root@k8s-master ~]# kubectl create -f hostpath-pv.yaml
[root@k8s-master~]#kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv-hostpath 10Gi RWO Retain Available pv-hostpath 5s
5. 基于 NFS 的 PV
（1）提前安裝好 nfs 服務
可以使用上一個案例中安裝好的 NFS，或重新安裝一臺，步驟如下：
提前安裝好 nfs 服務，192.168.10.101 是 nfs 服務器，也可以是任意一臺提供了 NFS 服務的主機。
客戶端需要在所有的 Kubernetes 節點安裝：
yum -y install nfs-utils
mkdir /opt/wwwroot
echo "This is my test file">/opt/wwwroot/index.html
vim /etc/exports
/opt/wwwroot 192.168.10.0/24(rw,sync,no_root_squash)
systemctl start nfs
systemctl start rpcbind
（2）創建一個基于 NFS 的 PV
PV 目前沒有 NameSpace 隔離，不需要指定命名空間，在任意命名空間下創建的 PV 均可以在其他 NameSpace 使用。
[root@k8s-master~]#cat<<EOF>nfs-pv.yaml
apiVersion:v1
kind:PersistentVolume
metadata:name:mypv-nfs
spec:capacity:storage:5GivolumeMode: FilesystemaccessModes :- ReadWriteOncepersistentVolumeReclaimPolicy: RecyclestorageClassName:pv-nfsmountOptions:- hard- nfsvers=4.1nfs:path:/opt/wwwroot/server:192.168.10.101
EOF
備注：
- capacity: 容量配置。
- volumeMode: 卷的模式，目前支持 Filesystem (文件系統) 和 Block (塊)，其中 Block 類型需要后端存儲支持，默認為文件系統。
- accessModes: 該 PV 的訪問模式。
- storageClassName:PV 的類，一個特定類型的 PV 只能綁定到特定類別的 PVC。
- persistentVolumeReclaimPolicy: 回收策略。
- mountoption: 非必要，新版本中已經棄用。
- nfs:NFS 服務配置，包括 path（NFS 上的共享目錄）和 server（NFS 的 IP 地址）。
（3）創建并查看 PV
[root@k8s-master ~]#kubectl create -fnfs-pv.yaml
[root@k8s-master~]#kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
mypv-hostpath 10Gi RWO Retain Available pv-hostpath 76s
mypv-nfs 5Gi RWO Recycle Available pv-nfs 4s
七、PersistentVolumeClaim（PVC，持久卷聲明）
當 kubernetes 管理員提前創建好了 PV，我們可以通過 PersistentVolumeClaim（簡稱 PVC）來使用它。PVC 是其他技術人員在 kubernetes 上對存儲的申請，它可以標明一個程序需要用到什么樣的后端存儲、多大的空間以及什么訪問模式進行掛載。這一點和 Pod 的 Qos 配置類似，Pod 消耗節點資源，PVC 消耗 PV 資源，Pod 可以請求特定級別的資源（CPU 和內存），PVC 可以請求特定的大小和訪問模式的 PV。例如申請一個大小為 5G 且只能被一個 Pod 只讀訪問的存儲。
在實際使用時，雖然用戶通過 PVC 獲取存儲支持，但是用戶可能需要具有不同性質的 PV 來解決不同的問題，比如使用 SSD 硬盤來提高性能。所以集群管理員需要根據不同的存儲后端來提供各種 PV，而不僅僅是大小和訪問模式的區別，并且無須讓用戶了解這些卷的具體實現方式和存儲類型，實現了存儲的解耦，降低了存儲使用的復雜度。
PVC 和 PV 進行綁定的前提條件是一些參數必須匹配，比如 accessModes、storageClassName、volumeMode 都需要相同，并且 PVC 的 storage 需要小于等于 PV 的 storage 配置。
1. PVC 的創建
（1）為 hostpath 類型的 PV 創建 PVC
[root@k8s-master ~]# vim pvc-hostpath.yaml
kind: PersistentVolumeClaim
apiVersion:v1
metadata:name:mypvc-hostpath
spec:storageClassName: pv-hostpathaccessModes:- ReadWriteOnceresources:requests:storage:3Gi
注意：
storageClassName: 存儲類名稱需要和對應的 PV 中的名稱一致，PV 和 PVC 進行綁定并非是名字相同，而是 StorageClassName 相同且其他參數一致才可以進行綁定。
創建并查看 PVC：
[root@k8s-master ~]#kubectl create -f pvc-hostpath.yaml
[root@k8s-master ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc-hostpath Bound mypv-hostpath 10Gi RWO pv-hostpath 4s
（2）為 NFS 類型的 PV 創建 PVC
[root@k8s-master ~]#cat pvc-nfs.yaml
kind: PersistentVolumeClaim
apiVersion:v1
metadata:name:mypvc-nfs
spec:storageClassName: pv-nfsaccessModes:- ReadWriteOnceresources:requests:storage:3Gi
注意：
storageClassName: 存儲類名稱需要和對應的 PV 中的名稱一致。
創建并查看 PVC：
[root@k8s-master ~]#kubectl create -f pvc-nfs.yaml
[root@k8s-master ~]# kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mypvc-hostpath Bound mypv-hostpath 10Gi RWO pv-hostpath 3m21s
mypvc-nfs Bound mypv-nfs 5Gi RWO pv-nfs 5s
從上述兩個簡單的例子可以看出，PVC 的定義和后端存儲并沒有關系。對于有存儲需求的技術人員，直接定義 PVC 即可綁定一塊 PV，之后就可以供 Pod 使用，而不用去關心具體的實現細節，大大降低了存儲的復雜度。
2. PVC 的使用
上述創建了 PV，并使用 PVC 與其綁定，接下來需要將 PVC 掛載到 Pod。和之前的掛載方式類似，PVC 的掛載也是通過 volumes 字段進行配置的，只不過之前需要根據不同的存儲后端填寫很多復雜的參數，而使用 PVC 進行掛載時，只填寫 PVC 的名字即可，不需要再關心任何的存儲細節，這樣即使不是 Kubernetes 管理員，不懂存儲的其他技術人員想要使用存儲，也可以非常簡單地進行配置和使用。
（1）創建 pod，綁定 hostpath 的 PV
[root@k8s-master ~]#cat pvc-pv-pod-hostpath.yaml
kind:Pod
apiVersion:v1
metadata:name:hostpath-pv-pod
spec:volumes:- name: task-pv-storagepersistentVolumeClaim:claimName:mypvc-hostpathcontainers:- name:task-pv-containerimage:nginx:1.7.9ports:- containerPort:80name:"http-server"volumeMounts:- mountPath:"/usr/share/nginx/html"name:task-pv-storage
備注：
claimName: mypvc-hostpath 是基于 hostpath 創建的 PVC 的名字。
創建并查看 Pod：
[root@k8s-master ~]#kubectl create -f pvc-pv-pod-hostpath.yaml
[root@k8s-master~]#ku get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
hostpath-pv-pod 1/1 Running 0 113s 10.244.85.204 k8s-node1 <none> <none>
測試掛載情況：
[root@k8s-node01~]#cd/mnt/data/
[root@k8s-node01 data]#touch aaa.txt
[root@k8s-master~]#ku exec -it hostpath-pv-pod -- bash
root@hostpath-pv-pod:/#ls /usr/share/nginx/html/
aaa.txt
（2）創建 pod，綁定 NFS 的 PV
[root@k8s-master ~]#cat pvc-pv-pod-nfs.yaml
kind:Pod
apiVersion: v1
metadata:name:pvc-nfs
spec:volumes:- name:pvc-nfs01persistentVolumeClaim:claimName:mypvc-nfscontainers:- name:task-pv-containerimage:nginx:1.7.9ports:- containerPort:80name:"http-server"volumeMounts:- mountPath:"/usr/share/nginx/html"name:pvc-nfs01
備注： claimName:mypvc-nfs 是基于 NFS 創建的 PVC 的名字。
創建并查看 Pod：
[root@k8s-master~]# kubectl create -f pvc-pv-pod-nfs.yaml
[root@k8s-master~]#ku get pod
NAME READY STATUS RESTARTS AGE
pvc-nfs 1/1 Running 0 4s
測試掛載情況：
[root@k8s-master~]#ku exec -it pvc-nfs -- bash
root@pvc-nfs:/#ls /usr/share/nginx/html/
index.html
)
