Dynamic provisioning of PersistentVolumes

集群管理员可以部署一个PersistentVolume provisoner(又名卷插件)，并定义一个或多个StorageClass对象，从而让用户选择他们想要的PersistentVolume类型。用户可以在其PersistentVolumeClaim中引用StorageClass，而provisoner在供应持久存储时将考虑到这一点。

注意：与PV类似，StorageClass资源不属于任何命名空间。

Kubernetes包含了最流行的云服务提供商的provisioner，所以管理员并不总是需要部署个provisioner。但是如果Kubernetes部署在本地，则需要配置定制的provisioner。

与管理员预先提供一组PV不同的是，他们需要定义一个或多个StorageClass并让系统在每次通过PVC请求PV时创建个新的PV。最重的是，不可能耗尽PV（很明显，你可能用完存储空间）。
image.png

6.6.1 通过 StorageClass 资源定义可用存储类型

首先，创建一个或多个StorageClass资源
image.png
该StorageClass资源指定了在PVC请求此StorageClass时应使用哪个provisioner来供应PV。在StorageClass定义文件中定义的parameter将传递给provisioner并仅限用于某个provisioner插件。该StorageClass使用Google Compute Engine (GCE) Persistent Disk (PD)的provisioner，这意味着当Kubernetes在GCE中运行时才可使用。对于其他云提供商，需要使用其它的provisioner。

6.6.2 在PVC中请求Storage class

创建StorageClass资源后，用户可以在PVC中按名称引用存储类。

创建一个请求特定存储类的PVC定义文件

image.png
当你创建声明时，PersistentVolume是由”fast” StorageClass资源中引用的provisioner创建的。即使现有的手动供应的PV与PVC匹配，也会使用该provisioner。

注意：如果在PVC中引用一个不存在的storage class，则PV的供应将失败。

检查所创建的PVC和动态供应的PV

image.png
image.png
可以看到动态供应的PV，其容量和访问模式是在PVC中所要求的。它的回收策略是Delete，这意味着当PVC被删除时，PV也将被删除。

了解存储类的使用

集群管理员可以创建具有不同性能或特性的多个存储类，然后研发人员再决定对应每一个声明最适合的存储类。
StorageClasses的好处在于，声明是通过名称引用它们的。因此，只要StorageClass名称在所有这些名称中相同， PVC 定义文件便可跨集群移植。一旦部署了存储类，作为集群用户，就可以像以前一样部署完全相同的 PVC 清单和完全相同的 pod 清单。

6.6.3 不指定存储类的动态供应

让我们看看PV附加到pod的最新和最简单的方法。

列出可用的存储类

以下是GKE中可用的存储类
image.png

检查默认存储类

查看standard (default) 存储类的更多信息
image.png

如果PVC没有明确指出要使用哪个存储类，default存储类会用于动态供应PV。

创建一个不指定存储类别的PVC

可以在不指定storageClassName属性的情况下创建PVC，并且(在Google Kubernetes Engine上)将为你提供pd-standard类型的GCE Persistent Disk。
image.png
在创建PVC时，将使用任何标记为default的存储类。以下为PVC创建后的情况：
image.png

强制将PVC绑定到预供应(pre-provisioned)的PV之一上

现在解释为什么在代码清单图6.11中将storageClassName设置为空字符串：
是为了确保PVC绑定到预供应的PV，而不是动态供应的新PV。
image.png

提示：如果希望PVC使用预先供应的PV,请将storageClassName显式设置为””。

了解动态持久卷供应的全貌

总而言之，将持久化存储附加到一个pod的最佳方式是仅创建PVC (如果需要，可以使用明确指定的storgeClassName) 和pod（其通过名称引用PVC) , 其他所有内容都由动态持久卷provisioner处理。

image.png