每次看到这些场景时，人们都会创建PV和PVC来绑定它，我想知道有什么需要？
因此，可以用volumeName: my-volume创建PVC，并将其绑定到现有的PV。或稍后创建PV，在这种情况下，PVC不会绑定到任何PV，它将永远保持Pending状态，直到使用给定名称创建PV为止。
现在，我的问题是为什么？为什么我们需要先创建PVC，然后再创建PV？在两种情况下，我认为它很有用：
persistentVolumeReclaimPolicy: Retain，然后是PV
不会被删除，但是会保持在Terminating状态。仍然，
我不确定您是否可以在Terminating状态下重新使用此PV。Openshift将其解释为 Binding 和 Pre-binding 。仍然没有提供用例的任何细节。
编辑
我知道什么是PV和PVC，以及何时使用它们，因此无需解释基础知识。我想知道同时创建两者的用例。
持久卷是物理上可以说的。像节点一样存在的实体。另一方面，PersistentVolumeClaim只是来自用户的请求。
打个比方，您必须认为PersistentVolume是一个节点，而PersistentVolumeClaim是一个pod。随着Pod消耗节点资源，PVC消耗PV资源。如official documentation中所述：
虽然PersistentVolumeClaims允许用户使用抽象存储资源，但是对于不同的问题，用户通常需要具有不同属性（例如性能）的PersistentVolumes。集群管理员需要能够提供各种持久卷，而不仅仅是大小和访问模式，这些持久卷在更多方面有所不同，而又不会使用户了解如何实现这些卷的细节。
总而言之，我要说PersistentVolumes和PersistentVolumeClaims是PV子系统的两个互补元素，它们可以协同工作，这就是从一开始就设计整个系统的方式。顺理成章的自然方法是先创建PV，然后再创建需要使用它的PVC。既然有一些实现某些东西的可能方法，这并不意味着它是推荐的，也不是它的设计方式。
Pvc可以使吊舱和固定体积之间进行光耦合。吊舱不知道底层存储是什么，也不一定知道这一点。它只是要求运行应用程序或服务所需的存储大小。该pvc声明将标识与pod存储需求匹配的持久卷，并将pv绑定到pod