是由管理者設定的存儲，它是群集的一部分。就像節點是叢集中的資源一樣，pv 也是叢集中的資源。 pv 是volume 之類的卷插件，但具有獨立于使用 pv 的 pod 的生命周期。
此 api 對象包含存儲實作的細節，即 nfs、iscsi 或特定于雲供應商的存儲系統。
是使用者存儲的請求。它與 pod 相似。pod 消耗節點資源，pvc 消耗 pv 資源。pod 可以請求特定級别的資源（cpu 和記憶體）。
聲明可以請求特定的大小和通路模式（例如，可以以讀/寫一次或 隻讀多次模式挂載）
叢集管理者建立一些 pv。它們帶有可供群集使用者使用的實際存儲的細節。它們存在于 kubernetes api 中，可用于消費。
當管理者建立的靜态 pv 都不比對使用者的 persistentvolumeclaim 時，叢集可能會嘗試動态地為 pvc 建立卷。
此配置基于 storageclasses ：pvc 必須請求 [存儲類]，并且管理者必須建立并配置該類才能進行動态建立。
聲明該類為 "" 可以有效地禁用其動态配置要啟用基于存儲級别的動态存儲配置，叢集管理者需要啟用 api server 上的 defaultstorageclass [準入控制器]。
例如，通過確定 defaultstorageclass 位于 api server 元件的 --admission-control 标志，使用逗号分隔的有序值清單中，可以完成此操作。
master 中的控制環路監視新的 pvc，尋找比對的 pv（如果可能），并将它們綁定在一起。如果為新的 pvc 動态調配 pv，則該環路将始終将該 pv 綁定到 pvc。
否則，使用者總會得到他們所請求的存儲，但是容量可能超出要求的數量。
一旦 pv 和 pvc 綁定後， persistentvolumeclaim 綁定是排他性的，不管它們是如何綁定的。
pvc 跟pv 綁定是一對一的映射
pvc 保護的目的是確定由 pod 正在使用的 pvc 不會從系統中移除，因為如果被移除的話可能會導緻資料丢失。
注意：當pod狀态為pending并且pod已經配置設定給節點或pod為running狀态時，pvc處于活動狀态。
當啟用pvc 保護 alpha 功能時，如果使用者删除了一個 pod 正在使用的 pvc，則該 pvc 不會被立即删除。pvc 的删除将被推遲，直到 pvc 不再被任何 pod 使用
persistentvolume 類型以插件形式實作。
kubernetes 目前支援以下插件類型：
gcepersistentdisk awselasticblockstore azurefile azuredisk fc (fibre channel)
flexvolume flocker nfs iscsi rbd (ceph block device) cephfs
cinder (openstack block storage) glusterfs vspherevolume quobyte volumes
hostpath vmware photon portworx volumes scaleio volumes storageos
持久卷示範代碼
persistentvolume 可以以資源提供者支援的任何方式挂載到主機上。如下表所示，供應商具有不同的功能，每個pv 的通路模式都将被設定為該卷支援的特定模式。例如，nfs 可以支援多個讀/寫用戶端，但特定的 nfs pv 可能以隻讀方式導出到伺服器上。每個 pv 都有一套自己的用來描述特定功能的通路模式
readwriteonce——該卷可以被單個節點以讀/寫模式挂載
readonlymany——該卷可以被多個節點以隻讀模式挂載
readwritemany——該卷可以被多個節點以讀/寫模式挂載
在指令行中，通路模式縮寫為：
rwo - readwriteonce
rox - readonlymany
rwx - readwritemany
一個卷一次隻能使用一種通路模式挂載，即使它支援很多通路模式。例如，gcepersistentdisk可以由單個節點作為readwriteonce模式挂載，或由多個節點以readonlymany模式挂載，但不能同時挂載。
retain（保留）——手動回收
recycle（回收）——基本擦除（ rm -rf /thevolume/* ）
delete（删除）——關聯的存儲資産（例如 aws ebs、gce pd、azure disk 和 openstack cinder 卷）将被删除
目前，隻有 nfs 和 hostpath 支援回收政策。aws ebs、gce pd、azure disk 和 cinder 卷支援删除政策
卷可以處于以下的某種狀态：
available（可用）——一塊空閑資源還沒有被任何聲明綁定
bound（已綁定）——卷已經被聲明綁定
released（已釋放）——聲明被删除，但是資源還未被叢集重新聲明
failed（失敗）——該卷的自動回收失敗
指令行會顯示綁定到 pv 的 pvc 的名稱
在非k8s節點（如harbor節點）安裝nfs伺服器
啟動harbor
在k8s的所有節點安裝nfs用戶端
測試是否可以挂載
多建立幾個pv
測試nfs是否正常
自動綁定
比對 pod name ( 網絡辨別 ) 的模式為：$(statefulset名稱)-$(序号)，比如上面的示例：web-0，web-1，web-2
statefulset 為每個 pod 副本建立了一個 dns 域名，這個域名的格式為： $(podname).(headless server name)，也就意味着服務間是通過pod域名來通信而非 pod ip，因為當pod所在node發生故障時， pod 會被飄移到其它 node 上，pod ip 會發生變化，但是 pod 域名不會有變化
statefulset 使用 headless 服務來控制 pod 的域名，這個域名的 fqdn 為：$(service name).$(namespace).svc.cluster.local，其中，“cluster.local” 指的是叢集的域名
根據 volumeclaimtemplates，為每個 pod 建立一個 pvc，pvc 的命名規則比對模式：(volumeclaimtemplates.name)-(pod_name)，比如上面的 volumemounts.name=www， pod name=web-[0-2]，是以建立出來的 pvc 是 www-web-0、www-web-1、www-web-2
删除 pod 不會删除其 pvc，手動删除 pvc 将自動釋放 pv
有序部署：部署statefulset時，如果有多個pod副本，它們會被順序地建立（從0到n-1）并且，在下一個pod運作之前所有之前的pod必須都是running和ready狀态。
有序删除：當pod被删除時，它們被終止的順序是從n-1到0。
有序擴充：當對pod執行擴充操作時，與部署一樣，它前面的pod必須都處于running和ready狀态。
穩定的持久化存儲，即pod重新排程後還是能通路到相同的持久化資料，基于 pvc 來實作。
穩定的網絡辨別符，即 pod 重新排程後其 podname 和 hostname 不變。
有序部署，有序擴充，基于 init containers 來實作。
有序收縮。
需要手動删除釋放
需要手動回收
内容來自https://study.163.com/course/coursemain.htm?courseid=1209568805