Menu
what exactly is the link between these two? how can i specify that PersistentVolumeClaim must use specific PersistentVolume? it seems to be sharing files between all PersistentVolumeClaims
813
A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory).
PVCs are requests for those resources and also act as claim checks to the resource. So a persistent volume (PV) is the "physical" volume on the host machine that stores your persistent data. A persistent volume claim (PVC) is a request for the platform to create a PV for you, and you attach PVs to your pods via a PVC.
PVs are cluster resources provisioned by an administrator, whereas PVCs are a user's request for storage and resources. PVCs consume PVs resources, but not vice versa. A PV is similar to a node in terms of cluster resources, while a PVC is like a Pod in the context of cluster resource consumption.
Once a PV is bound to a PVC, that PV is essentially tied to the PVC's project and cannot be bound to by another PVC. There is a one-to-one mapping of PVs and PVCs. However, multiple pods in the same project can use the same PVC.
Yes, this sharing as you stated it, is the case and you could say that this is at least very troubling if you want specific volumes for a given purpose. It is beneficial if you have random usable volumes, which is often not the case.
Scenario: Create a NFS volume for 1 database & a second volume for a second database. The database have to be retained between restarts of the pods/complete system reboots and have to be mounted again without issues later on.
To solve this scenario (within the constraints of Kubernetes) there are several possible solution paths:
Use the namespace as a solution to be able to prevent cross use of the volumes, resulting then in namespace issues since containers have to talk over the external (or flat) network to communicate with each other when crossing namespaces.
Another possible solution to solve this scenario is create the mount points using OS mounts and using the then present local volume. This will work, but requires maintenance of the OS template, something which we were trying to prevent using Kubernetes.
A third possible solutions is to have the NFS mount executed from within your container, thus avoiding the persistent volume approach completely, see How do you mount an external nfs share in Kubernetes? for this
183
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
