動態卷供應
動態卷供應允許按需建立儲存卷。如果沒有動態供應，叢集管理員必須手動呼叫其雲或儲存提供商來建立新的儲存卷，然後建立 PersistentVolume 物件以在 Kubernetes 中表示它們。動態供應功能消除了叢集管理員預先供應儲存的需要。相反，當用戶建立 PersistentVolumeClaim 物件時，它會自動供應儲存。
背景
動態卷供應的實現基於 API 組 storage.k8s.io 中的 API 物件 StorageClass。叢集管理員可以根據需要定義任意數量的 StorageClass 物件，每個物件都指定一個供應卷的卷外掛（也稱為供應器）以及在供應時要傳遞給該供應器的一組引數。叢集管理員可以在叢集中定義和公開多種儲存型別（來自相同或不同的儲存系統），每種型別都具有自定義引數集。這種設計還確保了終端使用者不必擔心儲存供應方式的複雜性和細微差別，但仍然能夠從多種儲存選項中進行選擇。
有關儲存類的更多資訊，請參閱此處。
啟用動態供應
要啟用動態供應，叢集管理員需要為使用者預先建立一個或多個 StorageClass 物件。StorageClass 物件定義了在呼叫動態供應時應使用哪個供應器以及應將哪些引數傳遞給該供應器。StorageClass 物件的名稱必須是有效的 DNS 子域名。
以下清單建立了一個名為“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.6 之前，這是透過 volume.beta.kubernetes.io/storage-class 註解完成的。然而，此註解自 v1.9 起已棄用。使用者現在可以並且應該改用 PersistentVolumeClaim 物件的 storageClassName 欄位。此欄位的值必須與管理員配置的 StorageClass 的名稱匹配（參見下文）。
例如，要選擇“fast”儲存類，使用者將建立以下 PersistentVolumeClaim：
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim1
spec:
accessModes:
- ReadWriteOnce
storageClassName: fast
resources:
requests:
storage: 30Gi
此宣告將自動供應一個 SSD 狀的持久盤。當宣告被刪除時，卷也將被銷燬。
預設行為
動態供應可以在叢集上啟用，以便在未指定儲存類時，所有宣告都將動態供應。叢集管理員可以透過以下方式啟用此行為：
- 將一個
StorageClass物件標記為預設； - 確保 API 伺服器上啟用了
DefaultStorageClass准入控制器。
管理員可以透過向 StorageClass 新增 storageclass.kubernetes.io/is-default-class 註解來將其標記為預設。當叢集中存在預設 StorageClass 且使用者建立未指定 storageClassName 的 PersistentVolumeClaim 時，DefaultStorageClass 准入控制器會自動新增指向預設儲存類的 storageClassName 欄位。
請注意，如果您將叢集中多個 StorageClass 上的 storageclass.kubernetes.io/is-default-class 註解設定為 true，並且您隨後建立了一個未設定 storageClassName 的 PersistentVolumeClaim，Kubernetes 將使用最近建立的預設 StorageClass。
拓撲感知
在 多區域 叢集中，Pod 可以分佈在區域的各個可用區中。單區域儲存後端應在 Pod 排程所在的可用區中進行供應。這可以透過設定 卷繫結模式 來實現。