動態卷供應允許按需建立儲存卷。 如果沒有動態供應，叢集管理員必須手動地聯絡他們的雲或儲存提供商來建立新的儲存卷， 然後在 Kubernetes 叢集建立 PersistentVolume 物件來表示這些卷。 動態供應功能消除了叢集管理員預先配置儲存的需要。 相反，它在使用者請求時自動供應儲存。

背景

動態卷供應的實現基於 storage.k8s.io API 組中的 StorageClass API 物件。 叢集管理員可以根據需要定義多個 StorageClass 物件，每個物件指定一個卷外掛（又名 provisioner）， 卷外掛向卷供應商提供在建立卷時需要的資料卷資訊及相關引數。

叢集管理員可以在叢集中定義和公開多種儲存（來自相同或不同的儲存系統），每種都具有自定義引數集。 該設計也確保終端使用者不必擔心儲存供應的複雜性和細微差別，但仍然能夠從多個儲存選項中進行選擇。

點選這裡查閱有關儲存類的更多資訊。

啟用動態卷供應

要啟用動態供應功能，叢集管理員需要為使用者預先建立一個或多個 StorageClass 物件。 StorageClass 物件定義當動態供應被呼叫時，哪一個驅動將被使用和哪些引數將被傳遞給驅動。 以下清單建立了一個 StorageClass 儲存類 "slow"，它提供類似標準磁碟的永久磁碟。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
 

以下清單建立了一個 "fast" 儲存類，它提供類似 SSD 的永久磁碟。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

使用動態卷供應

使用者通過在 PersistentVolumeClaim 中包含儲存類來請求動態供應的儲存。 在 Kubernetes v1.9 之前，這通過 volume.beta.kubernetes.io/storage-class 註解實現。然而，這個註解自 v1.6 起就不被推薦使用了。 使用者現在能夠而且應該使用 PersistentVolumeClaim 物件的 storageClassName 欄位。 這個欄位的值必須能夠匹配到叢集管理員配置的 StorageClass 名稱（見下面）。

例如，要選擇 “fast” 儲存類，使用者將建立如下的 PersistentVolumeClaim：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 30Gi

該宣告會自動供應一塊類似 SSD 的永久磁碟。 在刪除該聲明後，這個卷也會被銷燬。

設定預設值的行為

可以在群集上啟用動態卷供應，以便在未指定儲存類的情況下動態設定所有宣告。 叢集管理員可以通過以下方式啟用此行為：

• 標記一個 StorageClass 為 預設；
• 確保 DefaultStorageClass 准入控制器在 API 服務端被啟用。

管理員可以通過向其新增 storageclass.kubernetes.io/is-default-class 註解來將特定的 StorageClass 標記為預設。 當叢集中存在預設的 StorageClass 並且使用者建立了一個未指定 storageClassName 的 PersistentVolumeClaim 時， DefaultStorageClass 准入控制器會自動向其中新增指向預設儲存類的 storageClassName 欄位。

請注意，群集上最多隻能有一個 預設 儲存類，否則無法建立沒有明確指定 storageClassName 的 PersistentVolumeClaim。

拓撲感知

在多區域叢集中，Pod 可以被分散到多個區域。 單區域儲存後端應該被供應到 Pod 被排程到的區域。 這可以通過設定卷繫結模式來實現。