數據卷（Volume）
Container 中的文件在磁盤上是臨時存放的，這給 Container 中運行的較重要的應用程序帶來以下問題：
當容器崩潰時文件丟失：雖然 kubelet 會重新啟動容器，但容器會以干凈的狀態重啟；
在同一 Pod 中運行多個容器并需要共享文件。
Kubernetes 卷（Volume） 這一抽象概念能夠解決以上問題：
卷提供持久化存儲的機制，可以將容器中的文件存儲到持久化存儲介質（如網絡存儲、本地存儲等）上。當容器重新啟動時，可以重新掛載卷，使文件內容保持不變，確保數據的持久性和可靠性；
多個容器可以訪問相同的卷，從而實現容器之間的文件共享和通信。這對于需要共享數據的場景避免了復制和同步數據的開銷。
數據卷（Volume）作為Pod與外部存儲設備進行數據傳遞的通道，也是Pod內部容器間、Pod與Pod間、Pod與外部環境進行數據共享的方式。
Kubernetes提供了非常豐富的Volume類型，通常，Kubernetes內置提供的存儲卷插件可歸類為In-Tree類型，它們同Kubernetes源代碼一同發布和迭代，而由存儲服務商借助于CSI或FlexVolume接口擴展的獨立于Kubernetes代碼的存儲卷插件則統稱為Out-Of-Tree類型，目前CSI是較為推薦的擴展接口。
數據卷使用原則
一個Pod可以掛載多個Volume。
一個Pod可以掛載多種類型的Volume。
每個被Pod掛載的Volume卷，可以在不同的容器間共享。
Kubernetes環境推薦使用PVC和PV方式掛載Volume。
雖然單Pod可以掛載多個Volume，但是并不建議給一個Pod掛載過多數據卷。
說明
數據卷（Volume）生命周期和Pod一致，即Pod被刪除的時候，數據卷（Volume）也一起被刪除（Volume中的數據是否丟失取決于Volume的具體類型）。
PV和PVC
Kubernetes引入了PV（PersistentVolume）和PVC（PersistentVolumeClaim）兩個資源對象，用于定義、管理存儲。它們提供了抽象層，使得應用程序可以聲明其對存儲的需求，而無需關心具體基礎設施。
| 名稱 | 說明 |
|---|---|
| PV | 持久卷（PersistentVolume），是集群中的一塊存儲，可以由管理員事先制備， 或者使用存儲類（Storage Class）來動態制備。 持久卷是集群級別資源，就像節點也是集群資源一樣。PV 持久卷和普通的 Volume 一樣， 也是使用卷插件來實現的，只是它們擁有獨立于任何使用 PV 的 Pod 的生命周期。 |
| PVC | 持久卷聲明（PersistentVolumeClaim）， 表達的是用戶對存儲的請求。概念上與 Pod 類似。 Pod 會耗用節點資源，而 PVC 會耗用 PV 資源。Pod 可以請求特定數量的資源（CPU 和內存）；同樣 PVC 申領也可以請求特定的大小和訪問模式 。 |
以下是對PV及PVC典型字段說明：
| PV/PVC | 字段名稱 | 字段說明 |
|---|---|---|
PV
| 訪問模式 | 定義 PV 的訪問模式，包括：
|
| 回收策略 | PV對象的回收策略表示當PVC釋放時如何處理該數據卷。 回收策略包括：
| |
| 容量 | 定義 PV 的容量大小。 | |
| 卷模式 | Kubernetes 支持兩種卷模式：
| |
| 掛載選項 | 可以指定持久卷被掛載到節點上時使用的附加掛載選項。Kubernetes 不對掛載選項執行合法性檢查。如果掛載選項是非法的，掛載就會失敗。 說明： 并非所有持久卷類型都支持掛載選項。 | |
| 標簽 | 標簽（labels）是用于對 PV 對象進行標記和分類的元數據屬性，可以賦予 PV 以自定義的屬性或標識。 | |
| PVC | 訪問模式 | PVC（PersistentVolumeClaim）可以指定對持久化存儲的訪問模式需求； 在綁定 PV 時，系統將嘗試找到訪問模式滿足 PVC 需求的PV，否則PVC 將無法綁定到 PV。 |
| 卷模式 | Kubernetes 支持兩種卷模式：
| |
| 容量 | 表示PVC指定的容量。 說明： 當 PVC 與 已有PV 綁定時，PV 的容量必須大于或等于 PVC 所需的容量。否則，PV 將無法滿足 PVC 的需求，綁定將失敗。 | |
| 存儲類 | 可以通過為 storageClassName 屬性設置 storageClass 的名稱來請求特定的存儲類。 只有所請求的類的 PV 卷，即 storageClassName 值與 PVC 設置相同的 PV 卷， 才能綁定到 PVC 申領。 |
存儲卷掛載
容器存儲數據卷掛載有以下方式：靜態存儲卷、動態存儲卷。
靜態存儲卷
靜態存儲卷是由集群管理員預先創建的 PV（PersistentVolume）。管理員會根據集群中的存儲需求，提前分配一些存儲介質（如云盤、文件系統等），并創建相應的 PV 對象。這些 PV 對象處于可用狀態，等待 PVC（PersistentVolumeClaim）來使用和綁定。
當應用程序需要使用存儲服務時，可以通過定義 PVC 來申請所需的存儲資源。Kubernetes 將根據 PVC 的需求和相關的匹配規則，自動將 PVC 與合適的 PV 進行綁定（或者創建PVC時可以指定PV名稱）。這樣，應用程序就可以通過 PVC 訪問到預先創建的靜態存儲卷，獲得持久化的存儲能力。
動態存儲卷
Kubernetes使用存儲類（StorageClass），通過存儲插件提供動態存儲卷能力。
一般管理員根據集群中可用的存儲資源和策略，創建存儲類模板。應用開發者在部署應用程序時，通過定義 PVC 來申請所需的存儲資源。存儲插件會根據存儲類的定義與后端存儲池交互，創建一個符合需求的 PV，并將其綁定到 PVC 上。
動態存儲卷的優勢：
動態存儲卷讓Kubernetes實現了PV的自動化生命周期管理，PV的創建、刪除都通過Provisioner完成。
自動化創建PV對象，減少了配置復雜度和系統管理員的工作量。
動態卷可以實現PVC對存儲的需求容量和Provisioner出來的PV容量一致，實現存儲容量規劃最優。
掛在SubPath卷：Kubernetes提供了volumeMounts.subPath屬性配置，可用于指定所引用的卷內的子路徑，而不是其根路徑。
存儲類（StorageClass ）說明如下：
| 存儲驅動（provisioner） | 用來決定使用哪個卷插件制備 PV。 |
| 回收策略(reclaimPolicy) | 由 StorageClass 動態創建的 PV會在類的 reclaimPolicy 字段中指定回收策略，可以是 Delete 或者 Retain。如果 StorageClass 對象被創建時沒有指定 reclaimPolicy，默認為 Delete。 通過 StorageClass 手動創建并管理的 PV會使用它們被創建時指定的回收策略。 |
| 綁定模式（volumeBindingMode） | 該控制了卷綁定和動態供應應該發生在什么階段。 Immediate 模式：表示一旦創建了 PVC，也就完成了卷綁定和動態供應。 對于由于拓撲限制而非集群所有節點可達的存儲后端，PV會在不知道 Pod 調度要求的情況下綁定或者制備。 WaitForFirstConsumer模式： 該模式將延遲 PersistentVolume 的綁定和制備，直到使用該 PersistentVolumeClaim 的 Pod 被創建。 PV會根據 Pod 調度約束指定的拓撲來選擇或供應。 說明 volumeBindingMode配置為WaitForFirstConsumer，可以解決以下可能情況： 1、創建了A可用區的數據卷，但是A可用區的節點資源已經耗光，導致Pod啟動無法完成掛載。 2、集群管理員在規劃PVC、PV的時候不能確定在哪些可用區創建多個PV來備用。 |
| 卷擴展 | 當StorageClass 的 allowVolumeExpansion 字段設置為 true ，表示動態創建的PV可以配置為可擴展，即允許用戶通過編輯相應的 PVC 對象來調整卷大小。 |
| 掛載選項 | 由 StorageClass 動態創建的 PV 將使用類中 mountOptions 字段指定的掛載選項。 Kubernetes 不對掛載選項執行合法性檢查。如果掛載選項是非法的，掛載就會失敗。 說明 并非所有持久卷類型都支持掛載選項。 |
