pod 自身具有生命周期，是以其内部運作的容器及相關資料無法完成持久化，docker支援配置容器使用存儲卷将資料持久存儲于自身檔案系統之外的存儲系統，其可以是節點檔案系統或網絡檔案系統。相應的kubernetes 提供的存儲卷屬于pod資源級别，共享與pod内的所有容器，可用于在勇氣的檔案系統之外存儲應用程式的相關資料，甚至還可獨立于pod生命周期之外實作資料持久化
存儲卷： 定義在pod資源之上，可被其内部的所有容器挂載的共享目錄，它關聯至某外部的儲存設備之上的存儲空間，進而獨立于容器自身的檔案系統，而資料是否具有持久能力則取決于存儲卷自身能否支援持久化
empty: 其生命周期和pod資源相同 hostpath：其雖然可實作持久化存儲，但若pod被排程至其他節點，則該節點的存儲資源需要被遷移到指定節點，否則将無法持久化
nfs ceph glusterfs ... 其可實作資料的持久化存儲
secret： 用于向pod傳遞某些敏感資訊，如密碼、私鑰、證書等。 configmap：用于向pod中注入非敏感資料，如配置檔案，其可實作容器配置檔案集中化定義和管理
pod中定義的存儲有兩部分組成： 1 pods.spec.volumes： 用于定義在pod之上挂載的存儲卷清單，及存儲的來源 核心字段 pods.spec.volumes.name ： 用于定義此存儲卷的名稱，下面的挂載中需要通過此名稱關聯此存儲卷 pods.spec.volumes.type：用于指定此存儲卷的類型， 如emptydir、nfs、gitrepo等
2 pods.spec.containers.volumemounts ： 用于定義存儲卷被挂載到pod的位置及其相關的挂載形式 pods.spec.containers.volumemounts.mountpath ：用于定義挂載到目标容器的具體位置，如/usr/share/nginx/html pods.spec.containers.volumemounts.name： 用于引用上述存儲卷名稱。 pods.spec.containers.volumemounts.readonly ： 指定存儲卷是否為隻讀存儲卷。預設為false，及為讀寫存儲卷。 pods.spec.containers.volumemounts.subpath： 定義挂載存儲卷時使用的子路徑，及在mountpath指定的路徑下使用一個子路徑作為其挂載點。
emptydir 存儲卷生命周期與其pod相同，其長用于對資料緩存或臨時存儲，資料的共享等。 gitrepo 存儲卷可以看做是emptydir存儲卷的一種實際應用，使用該存儲卷的pod建立資源可以通過挂載目錄通路指定的代碼倉庫中的資料，使用gitrepo存儲卷的pod資源在建立時，會首先建立一個空目錄（emptydir）并克隆（clone）一份指定的git倉庫中的資料到該目錄，而後再建立容器并挂載該存儲卷。
pods.spec.volumes.emptydir 其主要包含兩個字段 pods.spec.volumes.emptydir.medium：此目錄所在的存儲媒體類型，取值有"default"或 "memory"，預設為"default"，表示使用節點的預設存儲媒體。"memory"則表示基于ram的臨時檔案系統tmpfs，空間受限于記憶體，但性能好，通常用于為容器中提供緩存空間。 pods.spec.volumes.emptydir.sizelimit： 用于指定目前存儲卷的限額，預設為nil,表示不限制。
執行個體
部署
檢視
測試
pods.spec.volumes.gitrepo.repository: git倉庫url，其是必選字段 pods.spec.volumes.gitrepo.directory: 目标目錄名稱，名稱中不能包含".."字元，"."表示将倉庫中的資料直接複制到卷目錄中，否則，為複制到卷目錄中以使用者指定的字元串為名稱的子目錄中。 pods.spec.volumes.gitrepo.revision: 特定的revision送出的哈希碼。 使用gitrepo存儲卷的pod資源運作的工作節點上必須安裝git程式，否則克隆倉庫的操作将無法完成，在1.12起，gitrepo存儲卷已經被廢棄。
yum -y install git
hostpath 類型的存儲卷時将工作節點上某個檔案系統的目錄或檔案挂載到pod中的一種存儲卷，可獨立于pod資源的生命周期，是以具有持久性，但其在本地，是以隻能應用于特定情況下的存儲卷的使用需求。
配置 hostpath 存儲卷的嵌套字段共有兩個： 1 用于指定工作節點上的目錄路徑的必選字段 pods.spec.volumes.hostpath.path 2 指定存儲卷類型type，它支援使用的卷類型包含 pods.spec.volumes.hostpath.type a directoryorcreate: 指定的路徑不存在時自動将其建立為權限為0755的空目錄，屬主屬組均為kubelet； b directory： 必須存在的檔案路徑 c fileorcreate： 指定的路徑不存在時自動将其建立的權限為0644的空檔案，屬主和屬組同樣是kubelet。 d file： 必須存在的檔案路徑 e socket： 必須存在的socket 檔案路徑 f chardevice： 必須存在的字元裝置檔案路徑 g blockdevice： 必須存在的塊裝置檔案路徑
這類pod資源通常受控于daemonset類型的pod控制器，起運作與叢集中的每個工作節點上，負責收集工作節點上系統級别的相關資料，但其不同節點的檔案或許不完全相同，于是，那些要求事先必須存在的檔案或目錄的滿足狀态也可能會不同，在節點中建立的檔案或目錄預設僅有root可寫，若期望容器内的程序有寫權限，則要麼将其設定為特權容器，要麼修改節點上的目錄路徑權限。
專用的網絡存儲卷： 1 傳統的nas或sam裝置（如 nfs，iscsi，fc） 2 分布式存儲 （clusterfs，rbd） 3 雲端存儲 4 建構在各類存儲系統上的抽象管理層等
pods.spec.volumes.nfs nfs 存儲卷在pod對象終止後僅僅是被解除安裝而非删除，其能夠實作排程的持久化存儲 核心字段： pods.spec.volumes.nfs.server ： 用于指定nfs伺服器的ip位址或主機名，必選字段 pods.spec.volumes.nfs.path： nfs 服務到處的檔案系統路徑，必選字段 pods.spec.volumes.nfs.readonly：是否以隻讀方式挂載，預設為false。
1 部署無密碼的nfs 服務。部署結果如下
2 配置相關執行個體并進行部署
配置相關網頁
測試結果
.
glusterfs （cluster filesystem）是一個開源的分布式檔案系統，是水準擴充存儲解決方案gluster的核心, glusterfs 通過擴充能夠支援數pb存儲容量和處理數千用戶端，glusterfs 借助tcp/ip 或 infiniband rdma網絡将實體分布式的存儲資源聚集在一起，使用單一全局名稱空間來管理資料，另外，glusterfs 基于可堆疊的使用者空間設計，可為各種不同資料負載提供優異的性能，是另一種流行的分布式存儲解決方案，要配置pod資源使用glusterfs存儲卷，需滿足： 1 存在某可用的glusterfs 存儲叢集 2 glusterfs 叢集中建立一個能滿足pod資源資料存儲需要的卷 3 在k8s 叢集内的各個節點上安裝glusterfs用戶端程式包
另外，若需要基于glusterfs使用存儲卷的動态供給機制，還需要事先部署heketi，他用于為glusterfs叢集提供restful 風格的管理接口，glusterfs 幾圈及hekei 的配置包含
endpoints<string>： endpoints 資源的名稱，此資源要事先存在，用于提供gluster叢集的部分節點資訊作為其通路入口，必選字段 path <string>： 用于到glusterfs叢集的卷路徑，如kube-redis，必選字段 readonly<boolean>： 是否為隻讀卷
注意 部署執行個體請參考 ：https://blog.csdn.net/phn_csdn/article/details/75153913?utm_source=debugrun&utm_medium=referral 需在節點上安裝 yum install -y glusterfs glusterfs-fuse
一個節點建立一個檔案夾，其他節點均可見
在其中注入内容
對象存儲節點檢視
通路測試
上述網絡存儲卷的缺點是：管理者使用者必須清晰了解所用到的網絡存儲系統的通路細節才能完成存儲卷相關的配置任務，這與kubernetes的向使用者和開發隐藏底層架構的目标相背離，對于存儲資源的好是能夠像計算資源一樣，使用者和開發人員無需了解pod資源挂載情況，無需了解存儲系統是什麼裝置以及位于何處，為此，kubernetes的persistentvolume子系統在使用者與管理者之間添加了一個抽象層，進而使得存儲系統的使用和管理直接解耦
對底層共享存儲的抽象，将共享存儲作為一種可由使用者申請使用的資源，實作了"存儲消費"機制，通過存儲插件，pv支援使用多種網絡存儲或雲端存儲等多種後端存儲系統。如nfs、rbd和cinder等。pv 是叢集級别的資源，其不屬于任何名稱空間，使用者對pv資源的使用需要pvc（persistendvolumeclaim）提出申請來完成綁定，是pv資源的消費者，其向pv申請特定大小的空間及相關的通路模式，進而建立出pvc存儲卷，而後再由pod資源通過persistentvolumeclaim 存儲卷關聯使用。
盡管pvc使得使用者可以以抽象的方式通路存儲資源，但很多時候還是會涉及pv的不少屬性，其兩者銜接方面的偏差必然導緻使用者的需求無法及時得到有效滿足。自kubernetes 1.4 版本來時引入了storageclass資源類型，其可用于将存儲資源定義為具有顯著特性的類别（class）而不是具體的pv，使用者通過pvc 直接向意向的類别發出申請，比對由管理者事先建立的pv，或者由其按需為使用者動态建立的pv,這樣做便免去了事先建立pv的過程。
各存儲卷支援的讀寫模式
available ： 可用狀态的自由資源，尚未被pvc綁定 bound： 已經被綁定的pvc released： 綁定的pvc已經被删除，但資源尚未被叢集回收 failed ： 因自動回收資源失敗而處于故障狀态
persistentvolumeclaim 是存儲卷類型資源，通過申請占用某個pv 而建立，其與pv是一對一的關系，使用者無需關心底層實作細節，隻需指定目标空間大小，通路模式、pv标簽選擇器和storageclass等相關資訊即可。
建立pvc
檢視服務
pods.spec.volumes.persistentvolumeclaim.claimname 綁定的pvc的名稱,必選字段 pods.spec.volumes.persistentvolumeclaim.readonly 綁定的模式
存儲類（storageclass）簡稱sc，其是kubernetes資源類型中的一種，是由管理者為管理pv友善而按需建立的類别，其可了解為pv的特性描述 通過向後端存儲傳輸資訊而達到和前端比對的效果 存儲類的好處之一就是支援pv的動态建立，用于用到持久性存儲時，需要通過建立pvc來綁定比對的pv，此類操作需求量較大，或當管理者建立的pv無法滿足pvc 需求時，系統按pvc 的需求标準動态建立适配的pv會為存儲管理帶來極大靈活性。 pvc 通過對存儲類的申請而擷取到pv
存儲類對象的名稱至關重要，是使用者調用的辨別，建立存儲類，除了名稱外，還需要為其定義三個關鍵字段 : provisioner（sc.provisioner 供給方）、parameter (參數 sc.provisioner)和 reclaimpolicy（回收政策sc.reclaimpolicy）
上述所需的環境請參考 :https://www.cnblogs.com/breezey/p/8849466.html kubernetes 節點上須有heketi 的key，需要有heketi-client 軟體，必須要加載核心子產品modprobe dm_thin_pool
如果有密碼認證，則編碼之前hekei的密碼
下屬執行個體中有密碼認證
2 動态pv供給
動态pv供給的啟用，需要實作由管理者建立至少一個存儲類，不同的provisoner 的建立方式各不相同。
支出存儲類的存儲資源
目前，在pvc的定義中指定使用的存儲類資源的方式有兩種：一種是使用pvc.spec.storageclassname，另一種是使用"volume.beta.kubernetes.io/storage-class" 資源注解，建議使用第一種方式，以免出現設定不同導緻的錯誤配置問題。 任何支援pv動态供給的存儲系統都可以在定義為存儲類後由pvc動态申請使用，存儲卷是必備資源，随着規模的變化，其也會随之而變動
配置pvc
pv 是叢集級别資源，而pvc則是資源需求，pvc發起對pv的申請，則兩個綁定，其pv和pvc是一一對應的關系，可用于響應pvc的pv必須能夠容納pvc的請求條件
靜态供給是由叢集管理者手動建立的一定數量的pv的資源供給方式，這些pv負責處理存儲系統的細節，并将由其抽象成易用的存儲資源供使用者使用，靜态提供的pv可能屬于某存儲類，也可能沒有存儲類
不存在某靜态的pv比對到使用者的pvc申請時，kubernetes叢集會嘗試為pvc動态建立符合需求的pv，此即為動态供給，這種方式依賴于存儲類的綁定，pvc必須向一個事先存在的存儲類發起動态配置設定pv的請求，沒有指定存儲類的pvc請求将會被禁止使用動态建立pv的方式。
使用者基于一系列存儲需求和通路模式定義好pvc後，kubernetes系統的控制器即會為其查找比對的pv，并于找到之後二者之間建立其關系，而後他們二者狀态轉換為綁定狀态，若pv是為pvc而動态建立的，則該pv專用于其pvc。 若是無法為pvc找到可比對的pv，則pvc将一直處于未綁定狀态，直到符合條件的pv出現并完成綁定方才可用
1 存儲使用 pod資源基于pod.spec.volumes.persistentvolumeclaim卷類型的定義，将標明的pvc關聯為存儲卷，而後即可為内部的容器使用，對于支援多中通路方式的存儲卷來說，使用者需要額外指定使用模式，一旦完成将存儲卷挂載至pod對象内的容器中，其應用即可使用關聯的pv提供存儲空間
2 pvc 保護 為了避免使用中的存儲卷被移除而導緻資料丢失，自kubernetes 1.9 開始當pod資源占用此pvc時，其不能删除pvc。
完成存儲卷的使用目标之後，即可删除pvc對象以便進行資源回收，政策如下
留存就是在删除pvc後，kubernetes不會自動删除pvm而僅僅是将其置于釋放狀态，不過，此狀态的pv尚且不能被其他pvc申請綁定，因為之前綁定成功的資料來存在，需要由管理者手動決定其後續處理方案，這就意味着，如果想要再次使用此類pv資源，則需要由管理者進行下面操作 1 删除pv，這之後，此pv的資料仍然存在于外部存儲 2 手工清理存儲之上遺留的資料 3 手工删除存儲系統級的存儲卷釋放空間，以便再次建立或直接重新建立pv
如果可被底層存儲插件支援，資源回收政策會在存儲卷上執行資料删除操作并讓pv資源再次變為可被claim。另外，管理者可配置一個自定義的回收器pod模闆，以便執行自定義回收操作
對于支援delete回收政策的存儲插件來說，在pvc被删除後會直接移除pv對象，同時移除的還有pv相關的外部存儲系統上的存儲資産，支援這種操作的存儲系統有aws ebs、gce pd、azure disk 或 cinder，動态建立的pv資源的回收差別于相關存儲類上的定義，存儲類上相關的預設政策為delete。
kubernetes 從1.8版本開始增加了擴充pv空間的特定，目前其支援的擴充pvc 機制的存儲卷有： gcepersistentdisk awselasticblockstore cinder rbd "persistentvolumeclaimresize"準入插件負責對支援空間大小變動的存儲卷執行更多的驗證操作，管理者需要事先啟用此插件才能使用pvc擴充機制， 對于包含檔案系統的存儲卷來說，隻有在新的pod資源基于讀寫模式開始使用pvc時才會執行檔案系統大小的調整工作，換句話說，如果某被擴充的存儲卷已經由pod資源使用，則需要重新建立此pod對象才能出發檔案系統大小的調整操作。支援空間調整的檔案系統有xfs、ext3和ext4