How persistent volume and persistence volume claim bound each other in kubernetes

Question

I am working on creating persistence volume & persistence volume claim in kubernetes. Both below configuration working fine and I am able to store the data in persistence volume storage path.

I created persistence volume

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
---

and Persistence volume claim:

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

Here there is no connection between persistence volume & persistence volume claim in above configuration files. How both are bound to each other.

Persistence volume & persistence volume claim

Say in deployment.yml, we can point the name of persistence volume claim. So that POD -> PVC -> PV -> host machine storage location.

Could anyone help me to understand the how persistence volume & persistence volume claim bound to each other by above configuration files.

Answer 1

In a nutshell binding between PV and PVC is decided by matching capacity and accessModes . Since you have 1Gi and ReadWriteOnce in both PV and PVC the binding was successful.

From the docs here

A user creates, or in the case of dynamic provisioning, has already created, a PersistentVolumeClaim with a specific amount of storage requested and with certain access modes. A control loop in the master watches for new PVCs, finds a matching PV (if possible), and binds them together. If a PV was dynamically provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, the user will always get at least what they asked for, but the volume may be in excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, using a ClaimRef which is a bi-directional binding between the PersistentVolume and the PersistentVolumeClaim.

Claims will remain unbound indefinitely if a matching volume does not exist. Claims will be bound as matching volumes become available. For example, a cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. The PVC can be bound when a 100Gi PV is added to the cluster

Answer 2

Do note that the storage classes(manual) in both the pv and pvc are the same which is one of the reasons they are bound.if they are different, then the pvc will go to pending status. It's imperative that they are the same to be bound. Hope this helps, You can also refer to this thread for various ways to bind. Can a PVC be bound to a specific PV?

PVC documentation:https://kubernetes.io/docs/concepts/storage/persistent-volumes/

PVCs don't necessarily have to request a class. A PVC with its storageClassName set equal to "" is always interpreted to be requesting a PV with no class, so it can only be bound to PVs with no class (no annotation or one set equal to ""). A PVC with no storageClassName is not quite the same and is treated differently by the cluster, depending on whether the DefaultStorageClass admission plugin is turned on.