Alpha 版本的動態卷，一個叢集同時只能允許單獨的、被硬編碼的提供者。也就是說，如果 Kubernetes 要提供動態卷的時候，即使叢集中可以使用多個儲存系統，Kubernetes 也只會使用同一個儲存卷外掛。儲存提供者的選型是基於雲環境型別決定的 —— AWS 的 EBS，Google Cloud 的 Persistent Disk 或者是 OpenStack 的 Cinder，以及 vSphere 的 vSphere Volume。另外只有容量引數可以配置。這就意味著，即使有其他引數可用，所有的動態卷除了尺寸大小，其他都是一樣的。

雖說這一功能的 Alpha 版本實用性有限，這畢竟是邁出了一步，有助於確定今後的發展方向。

Kubernetes 1.4 中加入了一個 新的 API 物件 StorageClass，可以定義多個 StorageClass 物件，並可以分別指定儲存外掛、設定引數，用於提供不同的儲存卷。這樣的設計讓叢集管理員能夠在同一個叢集內，定義和提供不同型別的、不同引數的卷（相同或者不同的儲存系統）。這樣的設計還確保了終端使用者在無需瞭解太多的情況下，有能力選擇不同的儲存選項。

叢集管理員定義併發布了兩個 StorageClass 物件

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

這一段建立了一個名為 “slow” 的 StorageClass，用於提供標準的持久儲存。

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

這一段建立了一個名為 “fast” 的 StorageClass，用於提供類似 SSD 的持久儲存。

使用者在 PersistentVolumeClaim 中可以包含一個 StorageClass 申請動態提供儲存。這一任務需要使用 volume.beta.kubernetes.io/storage-class 註解來完成。這一註解的值必須符合管理員配置的 StorageClass 名稱。

要選擇 “fast” 儲存類，使用者需要建立如下的 PVC：

{
  "kind": "PersistentVolumeClaim",
  "apiVersion": "v1",
  "metadata": {
    "name": "claim1",
    "annotations": {
        "volume.beta.kubernetes.io/storage-class": "fast"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "30Gi"
      }
    }
  }
}

上述報文會提供一個等效於 SSD 的持久盤，當這個 PVC 被刪除，這個卷也隨之銷燬。

所有的 PVC 都可以在不使用 StorageClass 註解的情況下，直接使用某個動態儲存。把一個StorageClass 物件標記為 “default” 就可以了。StorageClass 用註解storageclass.beta.kubernetes.io/is-default-class 就可以成為預設儲存。

有了預設的 StorageClass，使用者建立 PVC 就不用 storage-class 的註解了，1.4 中新加入的DefaultStorageClass 准入控制器會自動把這個標註指向預設儲存類。

Kubernetes 1.4 相容 alpha 版本的動態卷特性，讓使用者能夠平滑過渡到 beta 版本。用volume.alpha.kubernetes.io/storage-class 註解來標註 alpha 版本。

如果 Kubernetes 叢集部署在雲服務商，我們 考慮 自動使用雲的本地儲存系統建立一個動態卷供給者。例如在 AWS 上的標準部署會得到一個 EBS 的動態卷供給，而 Google Cloud 的部署則會提供一個 GCE PD 動態卷供應者。我們還在討論是否應該把這種