Alpha 版本的动态卷，一个集群同时只能允许单独的、被硬编码的提供者。也就是说，如果 Kubernetes 要提供动态卷的时候，即使集群中可以使用多个存储系统，Kubernetes 也只会使用同一个存储卷插件。存储提供者的选型是基于云环境类型决定的 —— AWS 的 EBS，Google Cloud 的 Persistent Disk 或者是 OpenStack 的 Cinder，以及 vSphere 的 vSphere Volume。另外只有容量参数可以配置。这就意味着，即使有其他参数可用，所有的动态卷除了尺寸大小，其他都是一样的。

虽说这一功能的 Alpha 版本实用性有限，这毕竟是迈出了一步，有助于确定今后的发展方向。

Kubernetes 1.4 中加入了一个 新的 API 对象 StorageClass，可以定义多个 StorageClass 对象，并可以分别指定存储插件、设置参数，用于提供不同的存储卷。这样的设计让集群管理员能够在同一个集群内，定义和提供不同类型的、不同参数的卷（相同或者不同的存储系统）。这样的设计还确保了最终用户在无需了解太多的情况下，有能力选择不同的存储选项。

集群管理员定义并发布了两个 StorageClass 对象

kind: StorageClassapiVersion: storage.k8s.io/v1beta1metadata:  name: slowprovisioner: kubernetes.io/gce-pdparameters:  type: pd-standard

这一段创建了一个名为 “slow” 的 StorageClass，用于提供标准的持久存储。

kind: StorageClassapiVersion: storage.k8s.io/v1beta1metadata:  name: fastprovisioner: kubernetes.io/gce-pdparameters:  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 动态卷供应者。我们还在讨论是否应该把这种卷作为缺省卷。