在之前的描述中，我们知道pv和pvc在使用中存在一种问题。pvc申请的的大小并不意味着就有符合pvc申请条件的pv。之前有意设定了符合pvc条件的pv，并成功的被pod绑定所使用。
StorageClass
k8s也考虑到这种情况，于是有意的设计了一种工作逻辑，能够让pvc在申请pv时候，借助存储类--->中间层(StorageClass)完成资源分配
首先，将众多存储归类，将相同的存储分为一个类别 ，这些被区分的存储类别分配后进行定义。定义成存储类(这类存储类是k8s标准资源)。这里资源定义完成后，k8s再去申请资源时候，将不会针对某个pv进行，而是针对存储类进行
- 定义存储类：以存储类型或者性能，在或者某一种标识特性进行分别区分来定义的类，就是存储类
restful
存储设备必须支持restful，并且存储空间必须满足pvc申请的空间，至少大于等于。
以NFS为例，假设此时并没有提前创建空间，也没有手动创建PV。在前端定义一个restful 风格的接口。用户请求在磁盘划分一个符合pvc大小的分区，而后编辑NFS的配置文件将划分的分区挂载至本地的某个目录并且导出。动态创建一个pv并且绑定导出的空间。而后与pvc绑定。这个过程的动作都是动态生成的。如下： 
也就是说事先并没有手动创建任何，只是输入了管理接口后远程创建，这类有ceph，Glusterfs等。
configMap与secret
secret与configMap也算是存储卷，但是secret与configMap存在的目的并不是为pod提供存储空间来用的，而是给用户提供从集群外部向pod内部应用注入配置信息的方式
引入：在之前，一个容器内的应用配置文件，在起初制作image的时候已经配置在镜像内制作完成。顶多使用变量传递而修改一些配置参数。但是，倘若修改后的容器在运行了一段时间后，又需要修改配置。需要重新传递参数，这时候就需要重启容器内的进程，或者脚本。从而使配置生效。
并且，在之前的场景中，配置文件写死在镜像内，如果有不同的配置那可能以为这需要制作多个镜像。倘若使用不同的镜像标识来做配置的更新迭代，那么就会出现很多不同版本的镜像。这在之前的场景中是常见的。 但是，如果仅仅修改一个配置文件，就需要重构一个镜像，这样的方式代价无疑较大。在一些非容器化常见的场景中，可以使用配置中心来进行管理配置文件，如下：
配置文件存放在配置中心，tomcat在启动时候加载配置文件是从配置中心拉取的内容，而后启动tomcat进程。而后如果需要修改配置文件，只需要修改配置中心的集中配置文件，而后通知程序重新加载配置即可
configMap
在kubernetes中引用一个新的标准资源，configMap来解决这个问题。configMap中存放的配置信息，启动一个pod的时候，可以共享configMap资源，资源对象可以作为存储卷或者环境变量。
configMap的作用在与可以与镜像解耦，配置信息通过configMap注入，一个配置文件可以应对多个pod容器，一个镜像也可以应付(配置)多个配置文件。这样一来便增强了应用的复用性和配置的一致性。一个configMap就是一系列配置数据的集合，而这些数据注入到pod对象容器中使用，注入方式有两种：1，直接使用configMap作为存储卷2，使用ENV FROM引用并且支持动态修改：修改完成同步到其他容器
comfigMap的存储模式是键值对：key1:value1。每个value的长度可以是一个，也可以是一串，没有字符长短限制。comfigMap存放的数据是明文的，而secret是base64
