<p>I am working on creating persistence volume &amp; persistence volume claim in kubernetes. Both below configuration working fine and I am able to store the data in persistence volume storage path.</p>
<p>I created persistence volume</p>
<pre><code>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: &quot;/mnt/data&quot; #host location
---
</code></pre>
<p>and Persistence volume claim:</p>
<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
</code></pre>
<p>Here there is no connection between persistence volume &amp; persistence volume claim in above configuration files. How both are bound to each other.</p>
<p><a href="https://i.stack.imgur.com/up5bl.png" rel="nofollow noreferrer">Persistence volume &amp; persistence volume claim</a></p>
<p>Say in deployment.yml, we can point the name of persistence volume claim. So that POD -&gt; PVC -&gt; PV -&gt; host machine storage location.</p>
<p>Could anyone help me to understand the how persistence volume &amp; persistence volume claim bound to each other by above configuration files.</p>

KARTHICK SANKAR
<p>In a nutshell binding between PV and PVC is decided by matching <code>capacity</code> and <code>accessModes</code>. Since you have <code>1Gi</code> and <code>ReadWriteOnce</code> in both PV and PVC the binding was successful.</p>
<p>From the docs <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#binding" rel="nofollow noreferrer">here</a></p>
<blockquote>
<p>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.</p>
<p>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</p>
</blockquote>
