一、Volume 的概念

????????對于大多數的項目而言，數據文件的存儲是非常常見的需求，比如存儲用戶上傳的頭像、文件以及數據庫的數據。在 Kubernetes 中，由于應用的部署具有高度的可擴展性和編排能力（不像傳統架構部署在固定的位置），因此把數據存放在容器中是非常不可取的，這樣也無法保障數據的安全。

????????我們應該把有狀態的應用變成無狀態的應用，意思是指把數據從應用中剝離出來，把產生的數據文件或者緩存的信息都放在云端，比如常用的 NFS（生產環境中不建議使用，因為存在單點故障，推薦使用分布式的存儲或者公有云的 NAS 服務 ）、ceph、GlusterFS、Minio 等。

????????在傳統的架構中，如果要使用這些存儲，需要提前在宿主機器掛載，然后程序才能訪問，在實際使用時，經常碰到新加節點忘記掛載存儲導致的一系列問題。而 Kubernetes 在設計之初就考慮了這些問題，并抽象出 Volume 的概念用于解決數據存儲的問題。

????????在容器中的磁盤文件是短暫的，當容器崩潰時，Kubelet 會重新啟動容器，但是容器運行時產生的數據文件都會丟失，之后容器會以干凈的狀態啟動。另外，當一個 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	橫向擴展	通過添加服務器節點實現存儲容量和性能的線性增長
	文件系統融合	可以將多個物理存儲資源整合為一個統一的命名空間，便于管理和使用
	多協議支持	支持 NFS、CIFS 等多種文件訪問協議，方便不同操作系統的客戶端訪問
	數據冗余	支持數據復制和條帶化，提供數據冗余保護和性能加速
iSCSI	基于 IP 網絡	利用現有的 IP 網絡基礎設施，降低存儲部署成本
	遠程存儲訪問	允許服務器通過網絡訪問遠程存儲設備，如同訪問本地硬盤一樣
	靈活性高	方便在不同服務器之間共享存儲資源，便于存儲資源的集中管理
	標準化協議	遵循 iSCSI 標準協議，具有良好的兼容性和互操作性
Cinder	OpenStack 組件	是 OpenStack 項目中負責塊存儲管理的組件，與 OpenStack 其他組件緊密集成
	多后端支持	支持多種后端存儲設備，如 Ceph、NFS 等，提供靈活的存儲選擇
	動態分配	可以根據虛擬機的需求動態分配和調整存儲容量
	快照和備份	支持創建卷快照和備份，便于數據保護和恢復
NFS	簡單易用	基于 UNIX/Linux 系統，使用簡單，易于部署和管理
	文件共享	允許不同的客戶端通過網絡共享文件，實現數據的集中存儲和訪問
	跨平臺支持	除了 UNIX/Linux 系統外，也可以在 Windows 等其他操作系統上通過安裝客戶端軟件來訪問
	性能較好	對于文件的讀取和寫入操作有較好的性能表現，適用于文件共享場景
RBD（RADOS Block Device）	Ceph 塊存儲	是 Ceph 存儲系統提供的塊存儲接口，依托 Ceph 的分布式架構
	高性能	通過條帶化等技術實現數據的并行讀寫，提供較高的 I/O 性能
	高可用	利用 Ceph 的多副本機制保障數據高可用性，確保數據的可靠性
	動態調整	可以根據業務需求動態調整存儲設備的大小
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

cat <<EOF> /root/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: {}
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、創建Deploymen

ku create -f nginx-empty.yaml
ku get pod

3、進入容器創建測試文件并驗證

ku exec -it nginx-8f8dcfd8c-rx2qr -c nginx01 -- bash
cd /opt
touch aaaku exec -it nginx-8f8dcfd8c-rx2qr -c nginx02 -- bash
cd /mnt
ls

四、使用 HostPath 掛載宿主機文件

????????HostPath 卷可以將節點上的文件或目錄掛載到 Pod 上，用于實現 Pod 和宿主機之間的數據共享，常用的示例有掛載宿主機的時區至 Pod，或者將 Pod 的日志文件掛載到宿主機等。

1、編寫 Deployment 文件，實現 HostPath 掛載

以下為使用 HostPath 卷的示例，實現將主機的 /etc/localtime 文件掛載到 Pod 的 /etc/localtime

cat <<EOF> /root/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）。

在配置 HostPath 時，有一個 type 參數，用于表達不同的掛載類型

HostPath 卷常用的類型有：

類型（type）	描述
空字符串	默認選項，在掛載 HostPath 卷之前不會有任何檢查
DirectoryOrCreate	如果給定的 path 不存在任何東西，那么將根據需要創建一個權限為 0755 的空目錄，和 kubelet 具有相同的組和權限
Directory	目錄必須存在于給定的路徑下
FileOrCreate	如果給定的路徑不存在任何內容，則會根據需要創建一個空文件，權限設置為 0644，和 kubelet 具有相同的組和所有權
File	文件，必須存在于給定的路徑中
Socket	UNIX 套接字，必須存在于給定的路徑中
CharDevice	字符設備，必須存在于給定的路徑中
BlockDevice	塊設備，必須存在于給定的路徑中

2、創建Deployment并查看

ku create -f nginx-hostPath.yaml
ku get pod

3、查看掛載

ku exec -it nginx-59f95c99b5-jlhgj -- bash
date

五、掛在NFS至容器

1、所有節點安裝NFS

dnf -y install nfs-utils

2、創建共享目錄

mkdir /opt/wwwroot
cd /opt/wwwroot/
echo "aaa">index.html
echo "/opt/wwwroot 192.168.10.0/24(rw,sync,no_root_squash)"> /etc/exports

3、編寫nfs的Deployment

cat <<EOF> /root/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

4、創建Deployment

ku create -f nginx-nfsVolume.yaml
ku get pod

5、驗證

ku get pod -o wide
curl 10.244.58.197

六、PersistentVolume（PV，持久卷）

????????對于很多復雜的需求，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 的存儲后端包括 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder 等

2、PV 訪問策略

????????在實際使用 PV 時，可能針對不同的應用會有不同的訪問策略，比如某類 Pod 可以讀寫，某類 Pod 只能讀，或者需要配置是否可以被多個不同的 Pod 同時讀寫等，此時可以使用 PV 的訪問策略進行簡單控制，目前支持的訪問策略如下：

訪問模式	描述	縮寫
ReadWriteOnce	單路可讀可寫，可以被單節點以讀寫模式掛載	RWO
ReadOnlyMany	多路只讀，可以被多節點以只讀模式掛載	ROX
ReadWriteMany	多路可讀可寫，可以被多個節點以讀寫模式掛載	RWX
ReadWriteOncePod	單節點只讀（1.22+），只能被一個 Pod 以讀寫的模式掛載	RWOP

????????雖然 PV 在創建時可以指定不同的訪問策略，但是也要后端的存儲支持才行。比如一般情況下，大部分塊存儲是不支持 ReadWriteMany 的。
在企業內，可能存儲很多不同類型的存儲，比如 NFS、Ceph、GlusterFS 等，針對不同類型的后端存儲具有不同的配置方式，這也是對集群管理員的一種挑戰，因為集群管理員需要對每種存儲都要有所了解。

3、PV 的配置方式

(1) 靜態配置

????????靜態配置是手動創建 PV 并定義其屬性，例如容量、訪問模式、存儲后端等。在這種情況下，Kubernetes 管理員負責管理和配置 PV，然后應用程序可以使用這些 PV。靜態配置通常用于一些固定的存儲后端，如 NFS。

(2) 動態配置

????????動態配置允許 Kubernetes 集群根據 PVC 的需求自動創建 PV，在這種情況下，管理員只需為存儲后端配置 StorageClass，然后應用程序就可以通過 PVC 請求存儲。Kubernetes 將自動創建與 PVC 匹配的 PV，并將其綁定到 PVC 上。這種方法使得存儲管理更加靈活和可擴展，允許管理員在集群中動態添加、刪除、和管理存儲資源

4、基于 HostPath 的 PV

????????可以創建一個基于 HostPath 的 PV，和配置 NFS 的 PV 類似，只需要配置 hostPath 字段即可，其它配置基本一致。

(1) 所有node節點創建主機目錄

mkdir /mnt/data

(2) 編輯hostpath類型的yaml文件

cat <<EOF> /root/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

ku create -f hostpath-pv.yaml
ku get pv

5、基于NFS類型的pv

(1) 所有節點安裝NFS

dnf -y install nfs-utils

(2) 創建共享目錄

mkdir /opt/wwwroot
cd /opt/wwwroot/
echo "aaa">index.html
echo "/opt/wwwroot 192.168.10.0/24(rw,sync,no_root_squash)"> /etc/exports
systemctl start nfs
systemctl start rpcbind
netstat -anpt | grep rpcbind

(3) 編輯一個基于NFS的PV(yaml文件)

cat <<EOF> /root/nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:name: mypv-nfs
spec:capacity:storage: 5GivolumeMode: FilesystemaccessModes:- ReadWriteOncepersistentVolumeReclaimPolicy: RecyclestorageClassName: pvc-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 地址

(4) 創建pv

ku create -f nfs-pv.yaml
ku get pv

七、PersistentVolumeClaim (PVC，持久卷聲明)

????????當 kubernetes 管理員提前創建好了 PV，我們又應該如何使用它呢？

????????這里介紹 kubernetes 的另一個概念 PersistentVolumeClaim（簡稱 PVC）。PVC 是其他技術人員在 kubernetes 上對存儲的申請，他可以標明一個程序需要用到什么樣的后端存儲、多大的空間以及什么訪問模式進行掛載。這一點和 Pod 的 QoS 配置類似，Pod 消耗節點資源，PVC 消耗 PV 資源，Pod 可以請求特定級別的資源（CPU 和內存），PVC 可以請求特定的大小和訪問模式的 PV。例如申請一個大小為 5G 且只能被一個 Pod 只讀訪問的存儲。

????????在實際使用時，雖然用戶通過 PVC 獲取存儲支持，但是用戶可能需要具有不同性質的 PV 來解決不同的問題，比如使用 SSD 硬盤來提高性能。所以集群管理員需要根據不同的存儲后端來提供各種 PV，而不僅僅是大小和訪問模式的區別，并且無須讓用戶了解這些卷的具體實現方式和存儲類型，打掃了存儲的解耦，降低了存儲使用的復雜度。

????????接下來我們來看看如何讓 PVC 和前面創建的 PV 綁定。PVC 和 PV 進行綁定的前提條件是一些參數必須匹配，比如 accessModes、storageClassName、volumeMode 都需要相同，并且 PVC 的 storage 需要小于等于 PV 的 storage 配置。

1、hostpath類型PVC 的創建

(1) 為 hostpath 類型的 PV 編輯PVC(yaml文件)

cat <<EOF> /root/pvc-hostpath.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: mypvc-hostpath
spec:storageClassName: pv-hostpathaccessModes:- ReadWriteOnceresources:requests:storage: 3Gi
EOF

????????storageClassName：存儲類名稱需要和對應的 PV 中的名稱一致，PV 和 PVC 進行綁定并非是名字相同，而是 StorageClassName 相同且其他參數一致才可以進行綁定。

(2) 創建PVC

ku create -f pvc-hostpath.yaml
ku get pvc
ku get pv

2、nfs類型PVC 的創建

(1) 編輯yaml文件

cat <<EOF> /root/pvc-nfs.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: mypvc-nfs
spec:storageClassName: pvc-nfsaccessModes:- ReadWriteOnceresources:requests:storage: 3Gi
EOF

????????storageClassName：存儲類名稱需要和對應的 PV 中的名稱一致，PV 和 PVC 進行綁定并非是名字相同，而是 StorageClassName 相同且其他參數一致才可以進行綁定。

(2) 創建PVC

ku create -f pvc-nfs.yaml
ku get pvc

3、PVC 的使用--基于hostpath

????????上述創建了 PV，并使用 PVC 與其綁定，現在還差一步就能讓程序使用這塊存儲，那就是將 PVC 掛載到 Pod。和之前的掛載方式類似，PVC 的掛載也是通過 volumes 字段進行配置的，只不過之前需要根據不同的存儲后端填寫很多復雜的參數，而使用 PVC 進行掛載時，只填寫 PVC 的名字即可，不需要再關心任何的存儲細節，這樣即使不是 Kubernetes 管理員，不懂存儲的其他技術人員想要使用存儲，也可以非常簡單地進行配置和使用。比如我們將之前創建的 hostPath 類型的 PVC 掛載到 Pod 中，可以看到只需要配置一個 ????????PersistentVolumeClaim 類型的 volumes，claimName 配置為 PVC 的名稱即可

(1) 編輯Pod關聯pvc的yaml文件

cat <<EOF> /root/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
EOF

claimName: mypvc-hostpath 是基于 hostpath 創建的 PVC 的名字

(2) 創建Pod

ku create -f pvc-pv-pod-hostpath.yaml
ku get pod -o wide

(3) 測試

cd /mnt/data/
echo "qwertyuiop">index.html
curl 10.244.58.198

4、PVC 的使用--基于nfs

(1) 編輯Pod關聯pvc的yaml文件

cat <<EOF> /root/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
EOF

(2) 創建pod

ku create -f pvc-pv-pod-nfs.yaml
ku get pod -o wide

(3) 測試

cd /opt/wwwroot/
echo "zxdctfvygbhunxctvybuhin7ui">index.html
curl 10.244.85.202