<p>Elaborating the question:</p>
<p>I have divided pods in two types for this question,</p>
<ol>
<li><p>An independent pod:
A pod made out of a separate yaml, and has nothing to do with production. Generally created for learning purposes.</p>
</li>
<li><p>A pod part of deployment:
Now, this pod is the part of a replicaset inside a deployment, and is created automatically while the deploying of a deployment. User doesn't create these pods explicitly.</p>
</li>
</ol>
<p>The actual question is:</p>
<p>Is there any difference in claiming a persistentVolume by these two type of pods.</p>
<p>Why this question?</p>
<p>Is because 2nd type of pod remain in 'PENDING' state, with an error message:</p>
<pre><code>&quot;0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.&quot;
</code></pre>
<p>And, the above error arises inspite of the particular pvs and pvcs are present on the cluster.
Explained more here:</p>
<p><a href="https://stackoverflow.com/questions/67585932/why-does-pod-status-remain-pending">Why does pod status remain &#39;PENDING&#39;?</a></p>

kkpareek
<p>There is no difference at all.
In a <code>Kubernetes</code> cluster, a <code>Pod</code> is a <code>Pod</code>, however it was created.</p>
<p>The problem you are facing with volume mounting can be caused by several different reasons.
Given the lack of information around your environment I can only list a few of the most common ones:</p>
<ul>
<li>You are mounting the same PVC on different Pods at the same time, but the <code>Persistent Volume</code>'s <code>Access Mode</code> does not support that (see <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">documentation</a>)</li>
<li>The PVC you are using for the &quot;Pending&quot; <code>Pod</code> does not have an associated <code>Persistent Volume</code> (there might be several reasons why this happens).</li>
<li>If you are in the cloud, the PV backing your PVC might be on a different availability zone from the Node where the Pod was scheduled in, making it impossible to mount.</li>
</ul>
<p>You might get more information by looking at the events of the Pending pod using <code>kubectl describe pod &lt;podname&gt;</code></p>
