如果我有 PersistentVolumeClaim，为什么我需要 PersistentVolume？

Question

每当我看到人们创建一个 PV 和一个 PVC 来绑定到这些场景时，我都想知道有什么需要？

因此，可以使用volumeName: my-volume 创建一个 PVC，并将其绑定到现有的 PV。或者稍后创建 PV，在这种情况下，PVC 不会绑定到任何 PV，它会永远保持 Pending 状态，直到使用给定名称创建 PV。

现在，我的问题是为什么？为什么我们需要先创建 PVC，然后再创建 PV？有两种情况我认为它有一半用处：

1. 当您不希望 PVC 创建具有随机名称的 PV，并且您 想要控制 PV 的名称，但即使在那种情况下，只要 使用您想要的名称创建 PV。为什么要创建 PVC？
2. 如果删除绑定了 PVC 的 PV 它与persistentVolumeReclaimPolicy: Retain，然后是PV 不会被删除，但会保持Terminating 状态。仍然， 我不确定您是否可以在 Terminating 状态下重复使用此 PV。

Openshift 将其解释为 绑定 和 预绑定。仍然没有给出用例的任何细节。

编辑

我知道什么是 PV 和 PVC，以及何时使用它们，因此无需解释基础知识。我想知道同时创建两者的用例。

Answer 1

Pvc 可以在 pod 和持久卷之间实现光耦合。 Pod 不知道底层存储是什么，也不一定知道。它只是请求运行应用程序或服务所需的存储大小。该 pvc 声明将识别与 pod 存储要求匹配的持久卷并将 pv 绑定到 pod

Answer 2

持久卷是物理上的东西。像节点一样存在的实体。另一方面，PersistentVolumeClaim 只是来自用户的请求。

打个比方，你一定认为 PersistentVolume 是一个节点，而 PersistentVolumeClaim 是一个 pod。由于 Pod 消耗节点资源，PVC 消耗 PV 资源。正如official documentation 中所述：

虽然 PersistentVolumeClaims 允许用户使用抽象存储资源，但对于不同的问题，用户通常需要具有不同属性（例如性能）的 PersistentVolume。集群管理员需要能够提供各种不同的 PersistentVolume，而不仅仅是大小和访问模式，而不是让用户了解这些卷的实施细节。

最后，我想说 PersistentVolumes 和 PersistentVolumeClaims 是 PV 子系统的两个互补元素，它们一起工作，这就是整个系统从一开始就被设计为使用的方式。合乎逻辑且自然的方式是首先创建 PV，然后是需要与之一起工作的 PVC。既然有不同的可能方式来实现某些东西，这并不意味着它是推荐的，或者它的设计方式。