如果我有一个PersistentVolumeClaim,为什么我需要一个PersistentVolume?

时间:2019-11-11 14:04:16

标签: kubernetes

每次看到这些场景时,人们都会创建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将其解释为 Binding Pre-binding 。仍然没有提供用例的任何细节。

编辑

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

2 个答案:

答案 0 :(得分:0)

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

打个比方,您必须认为PersistentVolume是一个节点,而PersistentVolumeClaim是一个pod。随着Pod消耗节点资源,PVC消耗PV资源。如official documentation中所述:

  

虽然PersistentVolumeClaims允许用户使用抽象存储资源,但是对于不同的问题,用户通常需要具有不同属性(例如性能)的PersistentVolumes。集群管理员需要能够提供各种持久卷,而不仅仅是大小和访问模式,这些持久卷在更多方面有所不同,而又不会使用户了解如何实现这些卷的细节。

总而言之,我要说PersistentVolumes和PersistentVolumeClaims是PV子系统的两个互补元素,它们可以协同工作,这就是从一开始就设计整个系统的方式。顺理成章的自然方法是先创建PV,然后再创建需要使用它的PVC。既然有一些实现某些东西的可能方法,这并不意味着它是推荐的,也不是它的设计方式。

enter image description here

答案 1 :(得分:0)

Pvc可以使吊舱和固定体积之间进行光耦合。吊舱不知道底层存储是什么,也不一定知道这一点。它只是要求运行应用程序或服务所需的存储大小。该pvc声明将标识与pod存储需求匹配的持久卷,并将pv绑定到pod