官方解释：持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者使用存储类（Storage Class）来动态供应。 持久卷是集群资源，就像节点也是集群资源一样。

个人理解：其实说白了，卷就是用来存储k8s容器数据的一个抽象概念，但是一般容器绑定的都是临时卷，容器重启之后就没了。有些数据在重启容器后可能仍然是被需要的，此时可以通过创建持久卷达到目的，它们拥有独立于任何使用pv的pod的生命周期。就像pod是集群的计算资源一样，pv则是集群中的存储资源。

官方解释：通过在 PersistentVolumeClaim 中指定PersistentVolume，你可以声明该特定 PV 与 PVC 之间的绑定关系。如果该 PersistentVolume 存在且未被通过其 claimRef 字段预留给 PersistentVolumeClaim，则该 PersistentVolume 会和该 PersistentVolumeClaim 绑定到一起。

个人理解：pvc的本质就是一个声明，某个pod可以先声明好需要怎样的存储资源，然后系统会根据策略和pv进行绑定。pvc和pv的关系与pod和node关系类似，pvc消耗pv的存储资源，pod消耗nod的计算资源，前者消耗后者的资源。用户只需要关注在容器中挂载pvc，而不需要关注pvc所绑定的pv底层存储是采用何种技术进行实现的。

官方解释：StorageClass 为管理员提供了描述存储 “类” 的方法。 不同的类型可能会映射到不同的服务质量等级或备份策略，或是由集群管理员制定的任意策略。 Kubernetes 本身并不清楚各种类代表的什么。这个类的概念在其他存储系统中有时被称为 “配置文件”。

个人理解：每个pv都是k8s集群中的存储资源，但是用户经常需要不同性能的pv，storageclass相当于隔离了不同性能的pv，集群管理员可以创建不同质量和策略的storageclass，对pv进行分类管理。

现在我们再回头看一下debug信息：PersistentVolumeClaim is not bound。毫无疑问，这句话的意思是说pvc没有绑定上pv。因为创建容器时指定的是pvc，pvc再去绑定相关的pv，应该是相关pv没有被创建出来，因此没有绑定上。于是研究了一番pv卷的供应过程，流程图如下图所示：

根据上图其实可以看出，pvc和pv的绑定过程其实是一个系统自动适配的过程，容器用pvc声明说我想要10g，然后刚好有个10g的pv，系统就给它俩绑定上了，容器就可以用上这个pv的存储资源了，在这个过程中，是先创建好若干pv，在容器中使用pvc时才会自动绑定到pc，这是一个静态供应的过程。

动态卷供应和静态卷供应的区别在于，动态卷供应的pv不是手动创建的，而是根据pvc的需求创建出来的。但是这个供应过程涉及到storageclass的定义，如果pvc中定义的storageclass为""，则直接使用默认的storageclass，此时需要看集群中是否有且只有一个默认的storageclass，并且如果没有启用Default准入控制器，则会直接禁用使用动态卷供应，只能通过静态卷供应方式给pvc绑定pv；如果pvc中已经指定了storageclass，则会直接基于该storageclass的配置生成pvc所需要的pv。这就是一个动态供应卷的过程。

基于以上背景，其实我们只要让这些容器通过动态卷供应的方式创建出pv，并将pvc绑定到对应pv即可，可以尝试进行以下几项排查。

使用如下指令查看StorageClass状态：

kubectl get sc

上图代表cbs为默认的StorageClass，使用动态卷供应时，如果没有配置相关的StorageClass，则会默认基于该StorageClass的配置创建pv。

修改默认StorageClass的方式如下：

kubectl patch storageclass cbs -p ‘{“metadata”: {“annotations”:{“storageclass.kubernetes.io/is-default-class”:“false”}}}’

使用如下指令启用指令控制器：

kube-apiserver --enable-admission-plugins=DefaultStorageClass

该准入控制器会监测没有指定任何StorageClass的pv创建， 并自动向其添加默认存储类。因此在没有开启该控制器时，由于没有填入默认存储类，最终导致动态卷供应的禁用。

由于每个StorageClass其实都会启动一个对应的容器，因此可以通过查看当前使用的StorageClass（默认或指定）的日志，定位具体的问题。
使用如下指令查看所有pod的名称：

kubectl get pods -A

使用如下指令查看相关Provisioner的日志：

kubectl logs -f cbs-provisioner-5bf7bb45f-2q5fg -n kube-system

在日志中会输出具体的绑定失败原因。我所遇到问题的原因：默认的StorageClass定义的规则是必须创建10G以上的pv，而在pvc中声明的仅为8G，因此通过动态卷供应策略无法创建出满足pvc条件的pv，最终导致绑定失败。修改后pvc中的size为10G后问题解决。