在上期，我们提到了，在kubernetes中，静态PV/PVC的存储分配方式，会在造成资源浪费的同时，很大一部分Pod的存储需求得不到满足。
这本质上是因为静态PV的指令性资源调配与未知的PVC需求之间的矛盾，表现的现象则是部分尺寸的PV卷产能过剩，而部分尺寸的PV卷产能不足。
让我们翻回新中国的经济发展史，我们会发现，每当国民经济的平衡明显发生偏移时，党中央就会动态调整资源调配，进行供给侧改革，让供给的产品更适应国民经济的需要。那么，我们有没有办法在kubernetes的存储分配中借鉴这一方法呢？
答案是肯定的——
这种机制叫做StorageClass。
StorageClass是一种对存储资源的抽象定义，提供了存储资源的动态供给模式。
让我们再看看前文中的栗子。
有3个Pod，叫做Pod A，Pod B和Pod C，分别通过PVC申请了3GiB, 2GiB和 5GiB的存储，并指定存储卷分别来自AWS-ebs(AWS提供的块存储服务)，RBD(前文提到过的Ceph块存储服务)和iSCSI(通用的通过TCP-IP实现的块存储服务)，如下表所示：
容量(GiB) | 卷提供者 | |
|---|---|---|
Pod A | 3.0 | AWS-ebs |
Pod B | 2.0 | RBD |
Pod C | 5.0 | iSCSI |
在应用了StorageClass之后，StorageClass层可以接管PVC，并根据PVC的请求，在StorageClass管理的存储池中为PVC请求分配卷，并挂载给Pod，如下图所示：
图中，StorageClass将存储资源分类为Golden, Silver和Bronze三个等级(Class)。这就是StorageClass的来历。
我们发现，StorageClass可以在AWS-ebs、Ceph RBD和普通iSCSI池中分配存储资源。它还能支持哪些资源呢？
我们翻开Kubernetes的文档:
https://kubernetes.io/docs/concepts/storage/storage-classes/
里面有一张表：
原来，StorageClass除了可以支持前面描述的三种存储之外，还能支持微软Azure(块和文件)，GlusterFS(文件)，OpenStack Cinder(OpenStack提供的块存储管理系统)，普通NFS(文件)，Vsphere (VMWare虚拟化系统中块存储管理系统)等数十种存储提供者。
与Kubernetes中大部分资源类似，存储资源在Kubernetes中，也使用yaml进行描述。以Vsphere为例：
代码语言：javascript复制apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: zeroedthick这个yaml中，provisioner字段描述了存储提供者为vsphere-volume，也就是指定了存储类型来自Vsphere。
parameters字段中，有一个参数diskformat为zeroedthick。这个参数是什么意思呢？
熟悉VMWare的同学可能会想起来，在esxi中创建虚拟磁盘的时候，磁盘分配方式有三个选项可选：
thin provision: 创建时虚拟磁盘并不分配所有空间，需要使用时再分配；
zeroedthick：创建时为虚拟磁盘分配所有空间；
eagerzeroedthick：创建时为虚拟磁盘分配所有空间并用0填充；
也就是说，Vsphere会接管这一参数，在创建磁盘时按照该参数创建！
但是，如果其他云存储系统不支持这一参数呢？
这个问题将留到后面解答。
另外一个问题是，如果我们期望把不在上述列表中的存储提供者也接入storageclass，有没有办法实现呢?
这两个问题我们在下期解答。
