建站
咨詢
售后
建站咨詢
新聞中心
介紹
存儲(chǔ)的管理是一個(gè)與計(jì)算實(shí)例的管理完全不同的問(wèn)題。PersistentVolume 子系統(tǒng)為用戶 和管理員提供了一組 API，將存儲(chǔ)如何供應(yīng)的細(xì)節(jié)從其如何被使用中抽象出來(lái)。 為了實(shí)現(xiàn)這點(diǎn)，我們引入了兩個(gè)新的 API 資源：PersistentVolume 和 PersistentVolumeClaim。
“只有客戶發(fā)展了，才有我們的生存與發(fā)展！”這是創(chuàng)新互聯(lián)建站的服務(wù)宗旨！把網(wǎng)站當(dāng)作互聯(lián)網(wǎng)產(chǎn)品，產(chǎn)品思維更注重全局思維、需求分析和迭代思維，在網(wǎng)站建設(shè)中就是為了建設(shè)一個(gè)不僅審美在線，而且實(shí)用性極高的網(wǎng)站。創(chuàng)新互聯(lián)對(duì)做網(wǎng)站、成都網(wǎng)站制作、網(wǎng)站制作、網(wǎng)站開(kāi)發(fā)、網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站優(yōu)化、網(wǎng)絡(luò)推廣、探索永無(wú)止境。
持久卷（PersistentVolume，PV）是集群中的一塊存儲(chǔ)，可以由管理員事先供應(yīng)，或者 使用存儲(chǔ)類（Storage Class）來(lái)動(dòng)態(tài)供應(yīng)。 持久卷是集群資源，就像節(jié)點(diǎn)也是集群資源一樣。PV 持久卷和普通的 Volume 一樣，也是使用 卷插件來(lái)實(shí)現(xiàn)的，只是它們擁有獨(dú)立于任何使用 PV 的 Pod 的生命周期。 此 API 對(duì)象中記述了存儲(chǔ)的實(shí)現(xiàn)細(xì)節(jié)，無(wú)論其背后是 NFS、iSCSI 還是特定于云平臺(tái)的存儲(chǔ)系統(tǒng)。
持久卷申領(lǐng)（PersistentVolumeClaim，PVC）表達(dá)的是用戶對(duì)存儲(chǔ)的請(qǐng)求。概念上與 Pod 類似。 Pod 會(huì)耗用節(jié)點(diǎn)資源，而 PVC 申領(lǐng)會(huì)耗用 PV 資源。Pod 可以請(qǐng)求特定數(shù)量的資源（CPU 和內(nèi)存）；同樣 PVC 申領(lǐng)也可以請(qǐng)求特定的大小和訪問(wèn)模式 （例如，可以要求 PV 卷能夠以 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany 模式之一來(lái)掛載，參見(jiàn)訪問(wèn)模式）。
盡管 PersistentVolumeClaim 允許用戶消耗抽象的存儲(chǔ)資源，常見(jiàn)的情況是針對(duì)不同的 問(wèn)題用戶需要的是具有不同屬性（如，性能）的 PersistentVolume 卷。 集群管理員需要能夠提供不同性質(zhì)的 PersistentVolume，并且這些 PV 卷之間的差別不 僅限于卷大小和訪問(wèn)模式，同時(shí)又不能將卷是如何實(shí)現(xiàn)的這些細(xì)節(jié)暴露給用戶。 為了滿足這類需求，就有了 存儲(chǔ)類（StorageClass） 資源。
卷和申領(lǐng)的生命周期
PV 卷是集群中的資源。PVC 申領(lǐng)是對(duì)這些資源的請(qǐng)求，也被用來(lái)執(zhí)行對(duì)資源的申領(lǐng)檢查。 PV 卷和 PVC 申領(lǐng)之間的互動(dòng)遵循如下生命周期：
供應(yīng)
PV 卷的供應(yīng)有兩種方式：靜態(tài)供應(yīng)或動(dòng)態(tài)供應(yīng)。
靜態(tài)供應(yīng)
集群管理員創(chuàng)建若干 PV 卷。這些卷對(duì)象帶有真實(shí)存儲(chǔ)的細(xì)節(jié)信息，并且對(duì)集群 用戶可用（可見(jiàn)）。PV 卷對(duì)象存在于 Kubernetes API 中，可供用戶消費(fèi)（使用）。
動(dòng)態(tài)供應(yīng)
如果管理員所創(chuàng)建的所有靜態(tài) PV 卷都無(wú)法與用戶的 PersistentVolumeClaim 匹配， 集群可以嘗試為該 PVC 申領(lǐng)動(dòng)態(tài)供應(yīng)一個(gè)存儲(chǔ)卷。 這一供應(yīng)操作是基于 StorageClass 來(lái)實(shí)現(xiàn)的：PVC 申領(lǐng)必須請(qǐng)求某個(gè) 存儲(chǔ)類，同時(shí)集群管理員必須 已經(jīng)創(chuàng)建并配置了該類，這樣動(dòng)態(tài)供應(yīng)卷的動(dòng)作才會(huì)發(fā)生。 如果 PVC 申領(lǐng)指定存儲(chǔ)類為 ?""?，則相當(dāng)于為自身禁止使用動(dòng)態(tài)供應(yīng)的卷。
為了基于存儲(chǔ)類完成動(dòng)態(tài)的存儲(chǔ)供應(yīng)，集群管理員需要在 API 服務(wù)器上啟用 ?DefaultStorageClass ?準(zhǔn)入控制器。 舉例而言，可以通過(guò)保證 ?DefaultStorageClass ?出現(xiàn)在 API 服務(wù)器組件的 ?--enable-admission-plugins? 標(biāo)志值中實(shí)現(xiàn)這點(diǎn)；該標(biāo)志的值可以是逗號(hào) 分隔的有序列表。
綁定
用戶創(chuàng)建一個(gè)帶有特定存儲(chǔ)容量和特定訪問(wèn)模式需求的 PersistentVolumeClaim 對(duì)象； 在動(dòng)態(tài)供應(yīng)場(chǎng)景下，這個(gè) PVC 對(duì)象可能已經(jīng)創(chuàng)建完畢。 主控節(jié)點(diǎn)中的控制回路監(jiān)測(cè)新的 PVC 對(duì)象，尋找與之匹配的 PV 卷（如果可能的話）， 并將二者綁定到一起。 如果為了新的 PVC 申領(lǐng)動(dòng)態(tài)供應(yīng)了 PV 卷，則控制回路總是將該 PV 卷綁定到這一 PVC 申領(lǐng)。 否則，用戶總是能夠獲得他們所請(qǐng)求的資源，只是所獲得的 PV 卷可能會(huì)超出所請(qǐng)求的配置。 一旦綁定關(guān)系建立，則 PersistentVolumeClaim 綁定就是排他性的，無(wú)論該 PVC 申領(lǐng)是 如何與 PV 卷建立的綁定關(guān)系。 PVC 申領(lǐng)與 PV 卷之間的綁定是一種一對(duì)一的映射，實(shí)現(xiàn)上使用 ClaimRef 來(lái)記述 PV 卷 與 PVC 申領(lǐng)間的雙向綁定關(guān)系。
如果找不到匹配的 PV 卷，PVC 申領(lǐng)會(huì)無(wú)限期地處于未綁定狀態(tài)。 當(dāng)與之匹配的 PV 卷可用時(shí)，PVC 申領(lǐng)會(huì)被綁定。 例如，即使某集群上供應(yīng)了很多 50 Gi 大小的 PV 卷，也無(wú)法與請(qǐng)求 100 Gi 大小的存儲(chǔ)的 PVC 匹配。當(dāng)新的 100 Gi PV 卷被加入到集群時(shí)，該 PVC 才有可能被綁定。
使用
Pod 將 PVC 申領(lǐng)當(dāng)做存儲(chǔ)卷來(lái)使用。集群會(huì)檢視 PVC 申領(lǐng)，找到所綁定的卷，并 為 Pod 掛載該卷。對(duì)于支持多種訪問(wèn)模式的卷，用戶要在 Pod 中以卷的形式使用申領(lǐng) 時(shí)指定期望的訪問(wèn)模式。
一旦用戶有了申領(lǐng)對(duì)象并且該申領(lǐng)已經(jīng)被綁定，則所綁定的 PV 卷在用戶仍然需要它期間 一直屬于該用戶。用戶通過(guò)在 Pod 的 ?volumes ?塊中包含 ?persistentVolumeClaim ?節(jié)區(qū)來(lái)調(diào)度 Pod，訪問(wèn)所申領(lǐng)的 PV 卷。
保護(hù)使用中的存儲(chǔ)對(duì)象
保護(hù)使用中的存儲(chǔ)對(duì)象（Storage Object in Use Protection）這一功能特性的目的 是確保仍被 Pod 使用的 PersistentVolumeClaim（PVC）對(duì)象及其所綁定的 PersistentVolume（PV）對(duì)象在系統(tǒng)中不會(huì)被刪除，因?yàn)檫@樣做可能會(huì)引起數(shù)據(jù)丟失。
當(dāng)使用某 PVC 的 Pod 對(duì)象仍然存在時(shí)，認(rèn)為該 PVC 仍被此 Pod 使用。
如果用戶刪除被某 Pod 使用的 PVC 對(duì)象，該 PVC 申領(lǐng)不會(huì)被立即移除。 PVC 對(duì)象的移除會(huì)被推遲，直至其不再被任何 Pod 使用。 此外，如果管理員刪除已綁定到某 PVC 申領(lǐng)的 PV 卷，該 PV 卷也不會(huì)被立即移除。 PV 對(duì)象的移除也要推遲到該 PV 不再綁定到 PVC。
你可以看到當(dāng) PVC 的狀態(tài)為 ?Terminating ?且其 ?Finalizers ?列表中包含 ?kubernetes.io/pvc-protection? 時(shí)，PVC 對(duì)象是處于被保護(hù)狀態(tài)的。
kubectl describe pvc hostpath
Name: hostpath
Namespace: default
StorageClass: example-hostpath
Status: Terminating
Volume:
Labels:
Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath
volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers: [kubernetes.io/pvc-protection] 你也可以看到當(dāng) PV 對(duì)象的狀態(tài)為 ?Terminating ?且其 ?Finalizers ?列表中包含 ?kubernetes.io/pv-protection? 時(shí)，PV 對(duì)象是處于被保護(hù)狀態(tài)的。
kubectl describe pv task-pv-volume
Name: task-pv-volume
Labels: type=local
Annotations:
Finalizers: [kubernetes.io/pv-protection]
StorageClass: standard
Status: Terminating
Claim:
Reclaim Policy: Delete
Access Modes: RWO
Capacity: 1Gi
Message:
Source:
Type: HostPath (bare host directory volume)
Path: /tmp/data
HostPathType:
Events: 回收
當(dāng)用戶不再使用其存儲(chǔ)卷時(shí)，他們可以從 API 中將 PVC 對(duì)象刪除，從而允許 該資源被回收再利用。PersistentVolume 對(duì)象的回收策略告訴集群，當(dāng)其被 從申領(lǐng)中釋放時(shí)如何處理該數(shù)據(jù)卷。 目前，數(shù)據(jù)卷可以被 Retained（保留）、Recycled（回收）或 Deleted（刪除）。
保留（Retain）
回收策略 ?Retain ?使得用戶可以手動(dòng)回收資源。當(dāng) PersistentVolumeClaim 對(duì)象 被刪除時(shí)，PersistentVolume 卷仍然存在，對(duì)應(yīng)的數(shù)據(jù)卷被視為"已釋放（released）"。 由于卷上仍然存在這前一申領(lǐng)人的數(shù)據(jù)，該卷還不能用于其他申領(lǐng)。 管理員可以通過(guò)下面的步驟來(lái)手動(dòng)回收該卷：
- 刪除 PersistentVolume 對(duì)象。與之相關(guān)的、位于外部基礎(chǔ)設(shè)施中的存儲(chǔ)資產(chǎn) （例如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）在 PV 刪除之后仍然存在。
- 根據(jù)情況，手動(dòng)清除所關(guān)聯(lián)的存儲(chǔ)資產(chǎn)上的數(shù)據(jù)。
- 手動(dòng)刪除所關(guān)聯(lián)的存儲(chǔ)資產(chǎn)。
如果你希望重用該存儲(chǔ)資產(chǎn)，可以基于存儲(chǔ)資產(chǎn)的定義創(chuàng)建新的 PersistentVolume 卷對(duì)象。
刪除（Delete）
對(duì)于支持 ?Delete ?回收策略的卷插件，刪除動(dòng)作會(huì)將 PersistentVolume 對(duì)象從 Kubernetes 中移除，同時(shí)也會(huì)從外部基礎(chǔ)設(shè)施（如 AWS EBS、GCE PD、Azure Disk 或 Cinder 卷）中移除所關(guān)聯(lián)的存儲(chǔ)資產(chǎn)。 動(dòng)態(tài)供應(yīng)的卷會(huì)繼承其 StorageClass 中設(shè)置的回收策略，該策略默認(rèn) 為 ?Delete?。 管理員需要根據(jù)用戶的期望來(lái)配置 StorageClass；否則 PV 卷被創(chuàng)建之后必須要被 編輯或者修補(bǔ)。
回收（Recycle）
回收策略 ?
Recycle?已被廢棄。取而代之的建議方案是使用動(dòng)態(tài)供應(yīng)。
如果下層的卷插件支持，回收策略 ?Recycle ?會(huì)在卷上執(zhí)行一些基本的 擦除（?rm -rf /thevolume/*?）操作，之后允許該卷用于新的 PVC 申領(lǐng)。
不過(guò)，管理員可以按 參考資料 中所述，使用 Kubernetes 控制器管理器命令行參數(shù)來(lái)配置一個(gè)定制的回收器（Recycler） Pod 模板。此定制的回收器 Pod 模板必須包含一個(gè) ?volumes ?規(guī)約，如下例所示：
apiVersion: v1
kind: Pod
metadata:
name: pv-recycler
namespace: default
spec:
restartPolicy: Never
volumes:
- name: vol
hostPath:
path: /any/path/it/will/be/replaced
containers:
- name: pv-recycler
image: "K8S.gcr.io/busybox"
command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"]
volumeMounts:
- name: vol
mountPath: /scrub定制回收器 Pod 模板中在 ?volumes ?部分所指定的特定路徑要替換為 正被回收的卷的路徑。
預(yù)留 PersistentVolume
通過(guò)在 PersistentVolumeClaim 中指定 PersistentVolume，你可以聲明該特定 PV 與 PVC 之間的綁定關(guān)系。如果該 PersistentVolume 存在且未被通過(guò)其 ?claimRef ?字段預(yù)留給 PersistentVolumeClaim，則該 PersistentVolume 會(huì)和該 PersistentVolumeClaim 綁定到一起。
綁定操作不會(huì)考慮某些卷匹配條件是否滿足，包括節(jié)點(diǎn)親和性等等。 控制面仍然會(huì)檢查 存儲(chǔ)類、訪問(wèn)模式和所請(qǐng)求的 存儲(chǔ)尺寸都是合法的。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: foo-pvc
namespace: foo
spec:
storageClassName: "" # 此處須顯式設(shè)置空字符串，否則會(huì)被設(shè)置為默認(rèn)的 StorageClass
volumeName: foo-pv
...此方法無(wú)法對(duì) PersistentVolume 的綁定特權(quán)做出任何形式的保證。 如果有其他 PersistentVolumeClaim 可以使用你所指定的 PV，則你應(yīng)該首先預(yù)留 該存儲(chǔ)卷。你可以將 PV 的 ?claimRef ?字段設(shè)置為相關(guān)的 PersistentVolumeClaim 以確保其他 PVC 不會(huì)綁定到該 PV 卷。
apiVersion: v1
kind: PersistentVolume
metadata:
name: foo-pv
spec:
storageClassName: ""
claimRef:
name: foo-pvc
namespace: foo
...
如果你想要使用 ?claimPolicy ?屬性設(shè)置為 ?Retain ?的 PersistentVolume 卷 時(shí)，包括你希望復(fù)用現(xiàn)有的 PV 卷時(shí)，這點(diǎn)是很有用的
擴(kuò)充 PVC 申領(lǐng)
FEATURE STATE: Kubernetes v1.11 [beta]
現(xiàn)在，對(duì)擴(kuò)充 PVC 申領(lǐng)的支持默認(rèn)處于被啟用狀態(tài)。你可以擴(kuò)充以下類型的卷：
- azureDisk
- azureFile
- awsElasticBlockStore
- cinder (deprecated)
- csi
- flexVolume (deprecated)
- gcePersistentDisk
- glusterfs
- rbd
- portworxVolume
只有當(dāng) PVC 的存儲(chǔ)類中將 ?allowVolumeExpansion ?設(shè)置為 true 時(shí)，你才可以擴(kuò)充該 PVC 申領(lǐng)。
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
resturl: "http://192.168.10.100:8080"
restuser: ""
secretNamespace: ""
secretName: ""
allowVolumeExpansion: true如果要為某 PVC 請(qǐng)求較大的存儲(chǔ)卷，可以編輯 PVC 對(duì)象，設(shè)置一個(gè)更大的尺寸值。 這一編輯操作會(huì)觸發(fā)為下層 PersistentVolume 提供存儲(chǔ)的卷的擴(kuò)充。 Kubernetes 不會(huì)創(chuàng)建新的 PV 卷來(lái)滿足此申領(lǐng)的請(qǐng)求。 與之相反，現(xiàn)有的卷會(huì)被調(diào)整大小。
直接編輯 PersistentVolume 的大小可以阻止該卷自動(dòng)調(diào)整大小。 如果對(duì) PersistentVolume 的容量進(jìn)行編輯，然后又將其所對(duì)應(yīng)的 PersistentVolumeClaim 的 ?
.spec? 進(jìn)行編輯，使該 PersistentVolumeClaim 的大小匹配 PersistentVolume 的話，則不會(huì)發(fā)生存儲(chǔ)大小的調(diào)整。 Kubernetes 控制平面將看到兩個(gè)資源的所需狀態(tài)匹配，并認(rèn)為其后備卷的大小 已被手動(dòng)增加，無(wú)需調(diào)整。
CSI 卷的擴(kuò)充
FEATURE STATE: Kubernetes v1.16 [beta]
對(duì) CSI 卷的擴(kuò)充能力默認(rèn)是被啟用的，不過(guò)擴(kuò)充 CSI 卷要求 CSI 驅(qū)動(dòng)支持 卷擴(kuò)充操作。
重設(shè)包含文件系統(tǒng)的卷的大小
只有卷中包含的文件系統(tǒng)是 XFS、Ext3 或者 Ext4 時(shí)，你才可以重設(shè)卷的大小。
當(dāng)卷中包含文件系統(tǒng)時(shí)，只有在 Pod 使用 ?ReadWrite ?模式來(lái)使用 PVC 申領(lǐng)的 情況下才能重設(shè)其文件系統(tǒng)的大小。 文件系統(tǒng)擴(kuò)充的操作或者是在 Pod 啟動(dòng)期間完成，或者在下層文件系統(tǒng)支持在線 擴(kuò)充的前提下在 Pod 運(yùn)行期間完成。
如果 FlexVolumes 的驅(qū)動(dòng)將 ?RequiresFSResize ?能力設(shè)置為 true，則該 FlexVolume 卷（于 Kubernetes v1.23 棄用）可以在 Pod 重啟期間調(diào)整大小。
重設(shè)使用中 PVC 申領(lǐng)的大小
FEATURE STATE: Kubernetes v1.15 [beta]
Kubernetes 從 1.15 版本開(kāi)始將調(diào)整使用中 PVC 申領(lǐng)大小這一能力作為 Beta 特性支持；該特性在 1.11 版本以來(lái)處于 Alpha 階段。 ?
ExpandInUsePersistentVolumes?特性必須被啟用；在很多集群上，與此類似的 Beta 階段的特性是自動(dòng)啟用的。
在這種情況下，你不需要?jiǎng)h除和重建正在使用某現(xiàn)有 PVC 的 Pod 或 Deployment。 所有使用中的 PVC 在其文件系統(tǒng)被擴(kuò)充之后，立即可供其 Pod 使用。 此功能特性對(duì)于沒(méi)有被 Pod 或 Deployment 使用的 PVC 而言沒(méi)有效果。 你必須在執(zhí)行擴(kuò)展操作之前創(chuàng)建一個(gè)使用該 PVC 的 Pod。
與其他卷類型類似，F(xiàn)lexVolume 卷也可以在被 Pod 使用期間執(zhí)行擴(kuò)充操作。
FlexVolume 卷的重設(shè)大小只能在下層驅(qū)動(dòng)支持重設(shè)大小的時(shí)候才可進(jìn)行。
擴(kuò)充 EBS 卷的操作非常耗時(shí)。同時(shí)還存在另一個(gè)配額限制： 每 6 小時(shí)只能執(zhí)行一次（尺寸）修改操作。
處理擴(kuò)充卷過(guò)程中的失敗
如果用戶指定的新大小過(guò)大，底層存儲(chǔ)系統(tǒng)無(wú)法滿足，PVC 的擴(kuò)展將不斷重試， 直到用戶或集群管理員采取一些措施。這種情況是不希望發(fā)生的，因此 Kubernetes 提供了以下從此類故障中恢復(fù)的方法。
- 集群管理員手動(dòng)處理
- 將綁定到 PVC 申領(lǐng)的 PV 卷標(biāo)記為 ?
Retain?回收策略； - 刪除 PVC 對(duì)象。由于 PV 的回收策略為 ?
Retain?，我們不會(huì)在重建 PVC 時(shí)丟失數(shù)據(jù)。 - 刪除 PV 規(guī)約中的 ?
claimRef?項(xiàng)，這樣新的 PVC 可以綁定到該卷。 這一操作會(huì)使得 PV 卷變?yōu)?nbsp;"可用（Available）"。 - 使用小于 PV 卷大小的尺寸重建 PVC，設(shè)置 PVC 的 ?
volumeName?字段為 PV 卷的名稱。 這一操作將把新的 PVC 對(duì)象綁定到現(xiàn)有的 PV 卷。 - 不要忘記恢復(fù) PV 卷上設(shè)置的回收策略。
- 通過(guò)請(qǐng)求擴(kuò)展為更小尺寸
如果擴(kuò)充下層存儲(chǔ)的操作失敗，集群管理員可以手動(dòng)地恢復(fù) PVC 申領(lǐng)的狀態(tài)并 取消重設(shè)大小的請(qǐng)求。否則，在沒(méi)有管理員干預(yù)的情況下，控制器會(huì)反復(fù)重試 重設(shè)大小的操作。
FEATURE STATE: Kubernetes v1.23 [alpha]
Kubernetes 從 1.23 版本開(kāi)始將允許用戶恢復(fù)失敗的 PVC 擴(kuò)展這一能力作為 alpha 特性支持。 ?
RecoverVolumeExpansionFailure?必須被啟用以允許使用此功能。
如果集群中的特性門控 ?ExpandPersistentVolumes ?和 ?RecoverVolumeExpansionFailure ?都已啟用，在 PVC 的擴(kuò)展發(fā)生失敗時(shí)，你可以使用比先前請(qǐng)求的值更小的尺寸來(lái)重試擴(kuò)展。 要使用一個(gè)更小的尺寸嘗試請(qǐng)求新的擴(kuò)展，請(qǐng)編輯該 PVC 的 ?.spec.resources? 并選擇 一個(gè)比你之前所嘗試的值更小的值。 如果由于容量限制而無(wú)法成功擴(kuò)展至更高的值，這將很有用。 如果發(fā)生了這種情況，或者你懷疑可能發(fā)生了這種情況，你可以通過(guò)指定一個(gè)在底層存儲(chǔ)供應(yīng)容量 限制內(nèi)的尺寸來(lái)重試擴(kuò)展。你可以通過(guò)查看 ?.status.resizeStatus? 以及 PVC 上的事件 來(lái)監(jiān)控調(diào)整大小操作的狀態(tài)。
請(qǐng)注意， 盡管你可以指定比之前的請(qǐng)求更低的存儲(chǔ)量，新值必須仍然高于 ?.status.capacity?。 Kubernetes 不支持將 PVC 縮小到小于其當(dāng)前的尺寸。
持久卷的類型
PV 持久卷是用插件的形式來(lái)實(shí)現(xiàn)的。Kubernetes 目前支持以下插件：
- awsElasticBlockStore - AWS 彈性塊存儲(chǔ)（EBS）
- azureDisk - Azure Disk
- azureFile - Azure File
- cephfs - CephFS volume
- csi - 容器存儲(chǔ)接口 (CSI)
- fc - Fibre Channel (FC) 存儲(chǔ)
- gcePersistentDisk - GCE 持久化盤
- glusterfs - Glusterfs 卷
- hostPath - HostPath 卷 （僅供單節(jié)點(diǎn)測(cè)試使用；不適用于多節(jié)點(diǎn)集群； 請(qǐng)嘗試使用 local 卷作為替代）
- iscsi - iSCSI (SCSI over IP) 存儲(chǔ)
- local - 節(jié)點(diǎn)上掛載的本地存儲(chǔ)設(shè)備
- nfs - 網(wǎng)絡(luò)文件系統(tǒng) (NFS) 存儲(chǔ)
- portworxVolume - Portworx 卷
- rbd - Rados 塊設(shè)備 (RBD) 卷
- vsphereVolume - vSphere VMDK 卷
以下的持久卷已被棄用。這意味著當(dāng)前仍是支持的，但是 Kubernetes 將來(lái)的發(fā)行版會(huì)將其移除。
- cinder - Cinder（OpenStack 塊存儲(chǔ)）（于 v1.18 棄用）
- flexVolume - FlexVolume （于 v1.23 棄用）
- flocker - Flocker 存儲(chǔ)（于 v1.22 棄用）
- quobyte - Quobyte 卷 （于 v1.22 棄用）
- storageos - StorageOS 卷（于 v1.22 棄用）
舊版本的 Kubernetes 仍支持這些“樹內(nèi)（In-Tree）”持久卷類型：
- ?
photonPersistentDisk?- Photon 控制器持久化盤。（v1.15 之后 不可用） - scaleIO - ScaleIO 卷（v1.21 之后 不可用）
持久卷
每個(gè) PV 對(duì)象都包含 ?spec ?部分和 ?status ?部分，分別對(duì)應(yīng)卷的規(guī)約和狀態(tài)。 PersistentVolume 對(duì)象的名稱必須是合法的 DNS 子域名.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.2在集群中使用持久卷存儲(chǔ)通常需要一些特定于具體卷類型的輔助程序。 在這個(gè)例子中，PersistentVolume 是 NFS 類型的，因此需要輔助程序 ?
/sbin/mount.nfs? 來(lái)支持掛載 NFS 文件系統(tǒng)。
容量
一般而言，每個(gè) PV 卷都有確定的存儲(chǔ)容量。 容量屬性是使用 PV 對(duì)象的 ?capacity ?屬性來(lái)設(shè)置的。
目前，存儲(chǔ)大小是可以設(shè)置和請(qǐng)求的唯一資源。 未來(lái)可能會(huì)包含 IOPS、吞吐量等屬性。
卷模式
FEATURE STATE: Kubernetes v1.18 [stable]
針對(duì) PV 持久卷，Kubernetes 支持兩種卷模式（?volumeModes?）：?Filesystem（文件系統(tǒng)）? 和 ?Block（塊）?。 ?volumeMode ?是一個(gè)可選的 API 參數(shù)。 如果該參數(shù)被省略，默認(rèn)的卷模式是 ?Filesystem?。
?volumeMode ?屬性設(shè)置為 ?Filesystem ?的卷會(huì)被 Pod 掛載（Mount） 到某個(gè)目錄。 如果卷的存儲(chǔ)來(lái)自某塊設(shè)備而該設(shè)備目前為空，Kuberneretes 會(huì)在第一次掛載卷之前 在設(shè)備上創(chuàng)建文件系統(tǒng)。
你可以將 ?volumeMode ?設(shè)置為 ?Block?，以便將卷作為原始?jí)K設(shè)備來(lái)使用。 這類卷以塊設(shè)備的方式交給 Pod 使用，其上沒(méi)有任何文件系統(tǒng)。 這種模式對(duì)于為 Pod 提供一種使用最快可能方式來(lái)訪問(wèn)卷而言很有幫助，Pod 和 卷之間不存在文件系統(tǒng)層。另外，Pod 中運(yùn)行的應(yīng)用必須知道如何處理原始?jí)K設(shè)備。
訪問(wèn)模式
PersistentVolume 卷可以用資源提供者所支持的任何方式掛載到宿主系統(tǒng)上。 如下表所示，提供者（驅(qū)動(dòng)）的能力不同，每個(gè) PV 卷的訪問(wèn)模式都會(huì)設(shè)置為 對(duì)應(yīng)卷所支持的模式值。 例如，NFS 可以支持多個(gè)讀寫客戶，但是某個(gè)特定的 NFS PV 卷可能在服務(wù)器 上以只讀的方式導(dǎo)出。每個(gè) PV 卷都會(huì)獲得自身的訪問(wèn)模式集合，描述的是 特定 PV 卷的能力。
訪問(wèn)模式有：
- ?
ReadWriteOnce? - ?
ReadOnlyMany? - ?
ReadWriteMany? - ?
ReadWriteOncePod?
卷可以被一個(gè)節(jié)點(diǎn)以讀寫方式掛載。 ReadWriteOnce 訪問(wèn)模式也允許運(yùn)行在同一節(jié)點(diǎn)上的多個(gè) Pod 訪問(wèn)卷。<
卷可以被多個(gè)節(jié)點(diǎn)以只讀方式掛載。
卷可以被多個(gè)節(jié)點(diǎn)以讀寫方式掛載。
卷可以被單個(gè) Pod 以讀寫方式掛載。 如果你想確保整個(gè)集群中只有一個(gè) Pod 可以讀取或?qū)懭朐?nbsp;PVC， 請(qǐng)使用ReadWriteOncePod 訪問(wèn)模式。這只支持 CSI 卷以及需要 Kubernetes 1.22 以上版本。
在命令行接口（CLI）中，訪問(wèn)模式也使用以下縮寫形式：
- RWO - ReadWriteOnce
- ROX - ReadOnlyMany
- RWX - ReadWriteMany
- RWOP - ReadWriteOncePod
重要提醒！ 每個(gè)卷同一時(shí)刻只能以一種訪問(wèn)模式掛載，即使該卷能夠支持 多種訪問(wèn)模式。例如，一個(gè) GCEPersistentDisk 卷可以被某節(jié)點(diǎn)以 ReadWriteOnce 模式掛載，或者被多個(gè)節(jié)點(diǎn)以 ReadOnlyMany 模式掛載，但不可以同時(shí)以兩種模式 掛載。
| 卷插件 | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod |
|---|---|---|---|---|
| AWSElasticBlockStore | - | - | - | |
| AzureFile | - | |||
| AzureDisk | - | - | - | |
| CephFS | - | |||
| Cinder | - | - | - | |
| CSI | 取決于驅(qū)動(dòng) | 取決于驅(qū)動(dòng) | 取決于驅(qū)動(dòng) | 取決于驅(qū)動(dòng) |
| FC | - | - | ||
| FlexVolume | 取決于驅(qū)動(dòng) | - | ||
| Flocker | - | - | - | |
| GCEPersistentDisk | - | - | ||
| Glusterfs | - | |||
| HostPath | - | - | - | |
| iSCSI | - | - | ||
| Quobyte | - | |||
| NFS | - | |||
| RBD | - | - | ||
| VsphereVolume | - | - （Pod 運(yùn)行于同一節(jié)點(diǎn)上時(shí)可行） | - | |
| PortworxVolume | - | - | ||
| StorageOS | - | - | - |
類
每個(gè) PV 可以屬于某個(gè)類（Class），通過(guò)將其 ?storageClassName ?屬性設(shè)置為某個(gè) StorageClass 的名稱來(lái)指定。 特定類的 PV 卷只能綁定到請(qǐng)求該類存儲(chǔ)卷的 PVC 申領(lǐng)。 未設(shè)置 ?storageClassName ?的 PV 卷沒(méi)有類設(shè)定，只能綁定到那些沒(méi)有指定特定 存儲(chǔ)類的 PVC 申領(lǐng)。
早前，Kubernetes 使用注解 ?volume.beta.kubernetes.io/storage-class? 而不是 ?storageClassName ?屬性。這一注解目前仍然起作用，不過(guò)在將來(lái)的 Kubernetes 發(fā)布版本中該注解會(huì)被徹底廢棄。
回收策略
目前的回收策略有：
- Retain -- 手動(dòng)回收
- Recycle -- 基本擦除 (?
rm -rf /thevolume/*?) - Delete -- 諸如 AWS EBS、GCE PD、Azure Disk 或 OpenStack Cinder 卷這類關(guān)聯(lián)存儲(chǔ)資產(chǎn)也被刪除
目前，僅 NFS 和 HostPath 支持回收（Recycle）。 AWS EBS、GCE PD、Azure Disk 和 Cinder 卷都支持刪除（Delete）。
掛載選項(xiàng)
Kubernetes 管理員可以指定持久卷被掛載到節(jié)點(diǎn)上時(shí)使用的附加掛載選項(xiàng)。
并非所有持久卷類型都支持掛載選項(xiàng)。
以下卷類型支持掛載選項(xiàng)：
- ?
awsElasticBlockStore? - ?
azureDisk? - ?
azureFile? - ?
cephfs? - ?
cinder?(已棄用于 v1.18) - ?
gcePersistentDisk? - ?
glusterfs? - ?
iscsi? - ?
nfs? - ?
quobyte?(已棄用于 v1.22) - ?
rbd? - ?
storageos?(已棄用于 v1.22) - ?
vsphereVolume?
Kubernetes 不對(duì)掛載選項(xiàng)執(zhí)行合法性檢查。如果掛載選項(xiàng)是非法的，掛載就會(huì)失敗。
早前，Kubernetes 使用注解 ?volume.beta.kubernetes.io/mount-options? 而不是 ?mountOptions ?屬性。這一注解目前仍然起作用，不過(guò)在將來(lái)的 Kubernetes 發(fā)布版本中該注解會(huì)被徹底廢棄。
節(jié)點(diǎn)親和性
每個(gè) PV 卷可以通過(guò)設(shè)置節(jié)點(diǎn)親和性來(lái)定義一些約束，進(jìn)而限制從哪些節(jié)點(diǎn)上可以訪問(wèn)此卷。 使用這些卷的 Pod 只會(huì)被調(diào)度到節(jié)點(diǎn)親和性規(guī)則所選擇的節(jié)點(diǎn)上執(zhí)行。 要設(shè)置節(jié)點(diǎn)親和性，配置 PV 卷 ?.spec? 中的 ?nodeAffinity?。
對(duì)大多數(shù)類型的卷而言，你不需要設(shè)置節(jié)點(diǎn)親和性字段。 AWS EBS、 GCE PD 和 Azure Disk 卷類型都能 自動(dòng)設(shè)置相關(guān)字段。 你需要為 local 卷顯式地設(shè)置 此屬性。
階段
每個(gè)卷會(huì)處于以下階段（Phase）之一：
- Available（可用）-- 卷是一個(gè)空閑資源，尚未綁定到任何申領(lǐng)；
- Bound（已綁定）-- 該卷已經(jīng)綁定到某申領(lǐng)；
- Released（已釋放）-- 所綁定的申領(lǐng)已被刪除，但是資源尚未被集群回收；
- Failed（失?。?- 卷的自動(dòng)回收操作失敗。
命令行接口能夠顯示綁定到某 PV 卷的 PVC 對(duì)象。
PersistentVolumeClaims
每個(gè) PVC 對(duì)象都有 ?spec ?和 ?status ?部分，分別對(duì)應(yīng)申領(lǐng)的規(guī)約和狀態(tài)。 PersistentVolumeClaim 對(duì)象的名稱必須是合法的 DNS 子域名.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 8Gi
storageClassName: slow
selector:
matchLabels:
release: "stable"
matchExpressions:
- {key: environment, operator: In, values: [dev]}訪問(wèn)模式
申領(lǐng)在請(qǐng)求具有特定訪問(wèn)模式的存儲(chǔ)時(shí)，使用與卷相同的訪問(wèn)模式約定。
卷模式
申領(lǐng)使用與卷相同的約定來(lái)表明是將卷作為文件系統(tǒng)還是塊設(shè)備來(lái)使用。
資源
申領(lǐng)和 Pod 一樣，也可以請(qǐng)求特定數(shù)量的資源。在這個(gè)上下文中，請(qǐng)求的資源是存儲(chǔ)。 卷和申領(lǐng)都使用相同的 資源模型。
選擇算符
申領(lǐng)可以設(shè)置標(biāo)簽選擇算符 來(lái)進(jìn)一步過(guò)濾卷集合。只有標(biāo)簽與選擇算符相匹配的卷能夠綁定到申領(lǐng)上。 選擇算符包含兩個(gè)字段：
- ?
matchLabels?- 卷必須包含帶有此值的標(biāo)簽 - ?
matchExpressions?- 通過(guò)設(shè)定鍵（key）、值列表和操作符（operator） 來(lái)構(gòu)造的需求。合法的操作符有 In、NotIn、Exists 和 DoesNotExist。
來(lái)自 ?matchLabels ?和 ?matchExpressions ?的所有需求都按邏輯與的方式組合在一起。 這些需求都必須被滿足才被視為匹配。
類
申領(lǐng)可以通過(guò)為 ?storageClassName ?屬性設(shè)置 StorageClass 的名稱來(lái)請(qǐng)求特定的存儲(chǔ)類。 只有所請(qǐng)求的類的 PV 卷，即 ?storageClassName ?值與 PVC 設(shè)置相同的 PV 卷， 才能綁定到 PVC 申領(lǐng)。
PVC 申領(lǐng)不必一定要請(qǐng)求某個(gè)類。如果 PVC 的 ?storageClassName ?屬性值設(shè)置為 ?""?， 則被視為要請(qǐng)求的是沒(méi)有設(shè)置存儲(chǔ)類的 PV 卷，因此這一 PVC 申領(lǐng)只能綁定到未設(shè)置 存儲(chǔ)類的 PV 卷（未設(shè)置注解或者注解值為 ?""? 的 PersistentVolume（PV）對(duì)象在系統(tǒng)中不會(huì)被刪除，因?yàn)檫@樣做可能會(huì)引起數(shù)據(jù)丟失。 未設(shè)置 ?storageClassName ?的 PVC 與此大不相同，也會(huì)被集群作不同處理。 具體篩查方式取決于 ?DefaultStorageClass ?準(zhǔn)入控制器插件 是否被啟用。
- 如果準(zhǔn)入控制器插件被啟用，則管理員可以設(shè)置一個(gè)默認(rèn)的 StorageClass。 所有未設(shè)置 ?
storageClassName?的 PVC 都只能綁定到隸屬于默認(rèn)存儲(chǔ)類的 PV 卷。 設(shè)置默認(rèn) StorageClass 的工作是通過(guò)將對(duì)應(yīng) StorageClass 對(duì)象的注解 ?storageclass.kubernetes.io/is-default-class? 賦值為 ?true?來(lái)完成的。 如果管理員未設(shè)置默認(rèn)存儲(chǔ)類，集群對(duì) PVC 創(chuàng)建的處理方式與未啟用準(zhǔn)入控制器插件 時(shí)相同。如果設(shè)定的默認(rèn)存儲(chǔ)類不止一個(gè)，準(zhǔn)入控制插件會(huì)禁止所有創(chuàng)建 PVC 操作。 - 如果準(zhǔn)入控制器插件被關(guān)閉，則不存在默認(rèn) StorageClass 的說(shuō)法。 所有未設(shè)置 ?
storageClassName?的 PVC 都只能綁定到未設(shè)置存儲(chǔ)類的 PV 卷。 在這種情況下，未設(shè)置 ?storageClassName?的 PVC 與 ?storageClassName?設(shè)置未 ?""? 的 PVC 的處理方式相同。
取決于安裝方法，默認(rèn)的 StorageClass 可能在集群安裝期間由插件管理器（Addon Manager）部署到集群中。
當(dāng)某 PVC 除了請(qǐng)求 StorageClass 之外還設(shè)置了 ?selector?，則這兩種需求會(huì)按 邏輯與關(guān)系處理：只有隸屬于所請(qǐng)求類且?guī)в兴?qǐng)求標(biāo)簽的 PV 才能綁定到 PVC。
目前，設(shè)置了非空 ?
selector?的 PVC 對(duì)象無(wú)法讓集群為其動(dòng)態(tài)供應(yīng) PV 卷。
早前，Kubernetes 使用注解 ?volume.beta.kubernetes.io/storage-class? 而不是 ?storageClassName ?屬性。這一注解目前仍然起作用，不過(guò)在將來(lái)的 Kubernetes 發(fā)布版本中該注解會(huì)被徹底廢棄。
使用申領(lǐng)作為卷
Pod 將申領(lǐng)作為卷來(lái)使用，并藉此訪問(wèn)存儲(chǔ)資源。 申領(lǐng)必須位于使用它的 Pod 所在的同一名字空間內(nèi)。 集群在 Pod 的名字空間中查找申領(lǐng)，并使用它來(lái)獲得申領(lǐng)所使用的 PV 卷。 之后，卷會(huì)被掛載到宿主上并掛載到 Pod 中。
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: nginx
volumeMounts:
- mountPath: "/var/www/html"
name: mypd
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim關(guān)于名字空間的說(shuō)明
PersistentVolume 卷的綁定是排他性的。 由于 PersistentVolumeClaim 是名字空間作用域的對(duì)象，使用 "Many" 模式（?ROX?、?RWX?）來(lái)掛載申領(lǐng)的操作只能在同一名字空間內(nèi)進(jìn)行。
類型為 hostpath 的 PersistentVolume
?hostPath ?PersistentVolume 使用節(jié)點(diǎn)上的文件或目錄來(lái)模擬網(wǎng)絡(luò)附加（network-attached）存儲(chǔ)。
原始?jí)K卷支持
FEATURE STATE: Kubernetes v1.18 [stable]
以下卷插件支持原始?jí)K卷，包括其動(dòng)態(tài)供應(yīng)（如果支持的話）的卷：
- AWSElasticBlockStore
- AzureDisk
- CSI
- FC （光纖通道）
- GCEPersistentDisk
- iSCSI
- Local 卷
- OpenStack Cinder
- RBD （Ceph 塊設(shè)備）
- VsphereVolume
使用原始?jí)K卷的持久卷
apiVersion: v1
kind: PersistentVolume
metadata:
name: block-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
volumeMode: Block
persistentVolumeReclaimPolicy: Retain
fc:
targetWWNs: ["50060e801049cfd1"]
lun: 0
readOnly: false申請(qǐng)?jiān)級(jí)K卷的 PVC 申領(lǐng)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: block-pvc
spec:
accessModes:
- ReadWriteOnce
volumeMode: Block
resources:
requests:
storage: 10Gi卷填充器（Populator）與數(shù)據(jù)源
FEATURE STATE: Kubernetes v1.22 [alpha]
Kubernetes 支持自定義的卷填充器；Kubernetes 1.18 版本引入了這個(gè) alpha 特性。 Kubernetes 1.22 使用重新設(shè)計(jì)的 API 重新實(shí)現(xiàn)了該機(jī)制。 確認(rèn)你正在閱讀與你的集群版本一致的 Kubernetes 文檔。
要檢查版本，請(qǐng)輸入 ?kubectl version?。
要使用自定義的卷填充器，你必須為 kube-apiserver 和 kube-controller-manager 啟用 ?
AnyVolumeDataSource?特性門控。
卷填充器利用了 PVC 規(guī)約字段 ?dataSourceRef?。 不像 ?dataSource ?字段只能包含對(duì)另一個(gè)持久卷申領(lǐng)或卷快照的引用， ?dataSourceRef ?字段可以包含對(duì)同一命名空間中任何對(duì)象的引用（不包含除 PVC 以外的核心資源）。 對(duì)于啟用了特性門控的集群，使用 ?dataSourceRef ?比 ?dataSource ?更好。
數(shù)據(jù)源引用
?dataSourceRef ?字段的行為與 ?dataSource ?字段幾乎相同。 如果其中一個(gè)字段被指定而另一個(gè)字段沒(méi)有被指定，API 服務(wù)器將給兩個(gè)字段相同的值。 這兩個(gè)字段都不能在創(chuàng)建后改變，如果試圖為這兩個(gè)字段指定不同的值，將導(dǎo)致驗(yàn)證錯(cuò)誤。 因此，這兩個(gè)字段將總是有相同的內(nèi)容。
在 ?dataSourceRef ?字段和 ?dataSource ?字段之間有兩個(gè)用戶應(yīng)該注意的區(qū)別：
- ?
dataSource?字段會(huì)忽略無(wú)效的值（如同是空值）， 而 ?dataSourceRef?字段永遠(yuǎn)不會(huì)忽略值，并且若填入一個(gè)無(wú)效的值，會(huì)導(dǎo)致錯(cuò)誤。 無(wú)效值指的是 PVC 之外的核心對(duì)象（沒(méi)有 apiGroup 的對(duì)象）。 - ?
dataSourceRef?字段可以包含不同類型的對(duì)象，而 ?dataSource?字段只允許 PVC 和卷快照。
用戶應(yīng)該始終在啟用了特性門控的集群上使用 ?dataSourceRef?，而在沒(méi)有啟用特性門控的集群上使用 ?dataSource?。 在任何情況下都沒(méi)有必要查看這兩個(gè)字段。 這兩個(gè)字段的值看似相同但是語(yǔ)義稍微不一樣，是為了向后兼容。 特別是混用舊版本和新版本的控制器時(shí)，它們能夠互通。
使用卷填充器
卷填充器是能創(chuàng)建非空卷的控制器， 其卷的內(nèi)容通過(guò)一個(gè)自定義資源決定。 用戶通過(guò)使用 ?dataSourceRef ?字段引用自定義資源來(lái)創(chuàng)建一個(gè)被填充的卷：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: populated-pvc
spec:
dataSourceRef:
name: example-name
kind: ExampleDataSource
apiGroup: example.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi因?yàn)榫硖畛淦魇峭獠拷M件，如果沒(méi)有安裝所有正確的組件，試圖創(chuàng)建一個(gè)使用卷填充器的 PVC 就會(huì)失敗。 外部控制器應(yīng)該在 PVC 上產(chǎn)生事件，以提供創(chuàng)建狀態(tài)的反饋，包括在由于缺少某些組件而無(wú)法創(chuàng)建 PVC 的情況下發(fā)出警告。
你可以把 alpha 版本的卷數(shù)據(jù)源驗(yàn)證器 控制器安裝到你的集群中。 如果沒(méi)有填充器處理該數(shù)據(jù)源的情況下，該控制器會(huì)在 PVC 上產(chǎn)生警告事件。 當(dāng)一個(gè)合適的填充器被安裝到 PVC 上時(shí)，該控制器的職責(zé)是上報(bào)與卷創(chuàng)建有關(guān)的事件，以及在該過(guò)程中發(fā)生的問(wèn)題。
在容器中添加原始?jí)K設(shè)備路徑的 Pod 規(guī)約
apiVersion: v1
kind: Pod
metadata:
name: pod-with-block-volume
spec:
containers:
- name: fc-container
image: fedora:26
command: ["/bin/sh", "-c"]
args: [ "tail -f /dev/null" ]
volumeDevices:
- name: data
devicePath: /dev/xvda
volumes:
- name: data
persistentVolumeClaim:
claimName: block-pvc向 Pod 中添加原始?jí)K設(shè)備時(shí)，你要在容器內(nèi)設(shè)置設(shè)備路徑而不是掛載路徑。
綁定塊卷
如果用戶通過(guò) PersistentVolumeClaim 規(guī)約的 ?volumeMode ?字段來(lái)表明對(duì)原始 塊設(shè)備的請(qǐng)求，綁定規(guī)則與之前版本中未在規(guī)約中考慮此模式的實(shí)現(xiàn)略有不同。 下面列舉的表格是用戶和管理員可以為請(qǐng)求原始?jí)K設(shè)備所作設(shè)置的組合。 此表格表明在不同的組合下卷是否會(huì)被綁定。
靜態(tài)供應(yīng)卷的卷綁定矩陣：
| PV volumeMode | PVC volumeMode | Result |
|---|---|---|
| 未指定 | 未指定 | 綁定 |
| 未指定 | Block | 不綁定 |
| 未指定 | Filesystem | 綁定 |
| Block | 未指定 | 不綁定 |
| Block | Block | 綁定 |
| Block | Filesystem | 不綁定 |
| Filesystem | Filesystem | 綁定 |
| Filesystem | Block | 不綁定 |
| Filesystem | 未指定 | 綁定 |
Alpha 發(fā)行版本中僅支持靜態(tài)供應(yīng)的卷。 管理員需要在處理原始?jí)K設(shè)備時(shí)小心處理這些值。
對(duì)卷快照及從卷快照中恢復(fù)卷的支持
FEATURE STATE: Kubernetes v1.17 [beta]
卷快照（Volume Snapshot）功能的添加僅是為了支持 CSI 卷插件。
要啟用從卷快照數(shù)據(jù)源恢復(fù)數(shù)據(jù)卷的支持，可在 API 服務(wù)器和控制器管理器上啟用 ?VolumeSnapshotDataSource ?特性門控。
基于卷快照創(chuàng)建 PVC 申領(lǐng)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: restore-pvc
spec:
storageClassName: csi-hostpath-sc
dataSource:
name: new-snapshot-test
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi卷克隆
卷克隆功能特性僅適用于 CSI 卷插件。
基于現(xiàn)有 PVC 創(chuàng)建新的 PVC 申領(lǐng)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: cloned-pvc
spec:
storageClassName: my-csi-plugin
dataSource:
name: existing-src-pvc-name
kind: PersistentVolumeClaim
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi編寫可移植的配置
如果你要編寫配置模板和示例用來(lái)在很多集群上運(yùn)行并且需要持久性存儲(chǔ)，建議你使用以下模式：
- 將 PersistentVolumeClaim 對(duì)象包含到你的配置包（Bundle）中，和 Deployment 以及 ConfigMap 等放在一起。
- 不要在配置中包含 PersistentVolume 對(duì)象，因?yàn)閷?duì)配置進(jìn)行實(shí)例化的用戶很可能 沒(méi)有創(chuàng)建 PersistentVolume 的權(quán)限。
- 為用戶提供在實(shí)例化模板時(shí)指定存儲(chǔ)類名稱的能力。
- 仍按用戶提供存儲(chǔ)類名稱，將該名稱放到 ?
persistentVolumeClaim.storageClassName? 字段中。 這樣會(huì)使得 PVC 在集群被管理員啟用了存儲(chǔ)類支持時(shí)能夠匹配到正確的存儲(chǔ)類， - 如果用戶未指定存儲(chǔ)類名稱，將 ?
persistentVolumeClaim.storageClassName? 留空（nil）。 這樣，集群會(huì)使用默認(rèn) ?StorageClass?為用戶自動(dòng)供應(yīng)一個(gè)存儲(chǔ)卷。 很多集群環(huán)境都配置了默認(rèn)的 ?StorageClass?，或者管理員也可以自行創(chuàng)建默認(rèn)的 ?StorageClass?。 - 在你的工具鏈中，監(jiān)測(cè)經(jīng)過(guò)一段時(shí)間后仍未被綁定的 PVC 對(duì)象，要讓用戶知道這些對(duì)象， 因?yàn)檫@可能意味著集群不支持動(dòng)態(tài)存儲(chǔ)（因而用戶必須先創(chuàng)建一個(gè)匹配的 PV），或者 集群沒(méi)有配置存儲(chǔ)系統(tǒng)（因而用戶無(wú)法配置需要 PVC 的工作負(fù)載配置）。
本文標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes持久卷
標(biāo)題網(wǎng)址：http://www.fisionsoft.com.cn/article/coggggs.html
