持久卷和持久卷声明如何在 Kubernetes 中相互绑定答案

【问题标题】：How persistent volume and persistence volume claim bound each other in kubernetes持久卷和持久卷声明如何在 Kubernetes 中相互绑定
【发布时间】：2020-11-08 14:55:02
【问题描述】：

我正在努力在 Kubernetes 中创建持久性卷和持久性卷声明。以下配置都工作正常，我能够将数据存储在持久卷存储路径中。

我创建了持久化卷

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-vol
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi #Size of the volume
  accessModes:
    - ReadWriteOnce #type of access
  hostPath:
    path: "/mnt/data" #host location
---

和持久性卷声明：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---

以上配置文件中的持久化卷和持久化卷声明之间没有联系。两者如何相互绑定。

Persistence volume & persistence volume claim

说在deployment.yml中，我们可以点持久化卷声明的名字。这样POD -> PVC -> PV -> 宿主机存储位置。

任何人都可以帮助我了解持久性卷和持久性卷声明如何通过上述配置文件相互绑定。

【问题讨论】：

标签： kubernetes kubernetes-pod

【解决方案1】：

简而言之，PV 和 PVC 之间的绑定取决于匹配 capacity 和 accessModes。由于您在 PV 和 PVC 中都有 1Gi 和 ReadWriteOnce，因此绑定成功。

来自文档here

用户创建，或者在动态配置的情况下，已经已创建，具有特定存储量的 PersistentVolumeClaim 请求并具有某些访问模式。主机中的控制回路监视新的 PVC，找到匹配的 PV（如果可能），并绑定他们在一起。如果为新 PVC 动态配置 PV，则循环将始终将该 PV 绑定到 PVC。否则，用户将总是至少得到他们要求的东西，但音量可能在超出要求。一旦绑定，PersistentVolumeClaim 就会绑定是排他性的，无论它们是如何绑定的。 PVC 到 PV 绑定是一对一的映射，使用一个双向的 ClaimRef PersistentVolume 和 PersistentVolumeClaim 之间的绑定。

如果匹配的卷不存在，则声明将无限期保持未绑定存在。当匹配的数量可用时，索赔将受到约束。为了例如，配置有许多 50Gi PV 的集群将不匹配 PVC 请求 100Gi。增加一个 100Gi PV 就可以绑定 PVC 集群

【讨论】：

【解决方案2】：

请注意 pv 和 pvc 中的存储类（手动）是相同的，这是它们被绑定的原因之一。如果它们不同，那么 pvc 将进入挂起状态。它们必须相同才能被绑定。希望对您有所帮助，您也可以参考此线程了解各种绑定方式。 Can a PVC be bound to a specific PV?

PVC 文档：https://kubernetes.io/docs/concepts/storage/persistent-volumes/

PVC 不一定要请求一个类。 storageClassName 设置为“”的 PVC 总是被解释为请求一个没有类的 PV，因此它只能绑定到没有类的 PV（没有注释或一组等于“”）。一个没有 storageClassName 的 PVC 不太一样，被集群区别对待，取决于 DefaultStorageClass 准入插件是否开启。

【讨论】：