我正在努力在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->主机存储位置。
任何人都可以帮助我了解以上配置文件如何将持久性卷和持久性卷声明相互绑定。
答案 0 :(得分:3)
简而言之,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 集群
答案 1 :(得分:0)
请注意,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准入插件。