Is there any difference in the process of claiming volume by a pod which is independent, and a pod which is part of a deployment?

5/19/2021

Elaborating the question:

I have divided pods in two types for this question,

  1. An independent pod: A pod made out of a separate yaml, and has nothing to do with production. Generally created for learning purposes.

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

The actual question is:

Is there any difference in claiming a persistentVolume by these two type of pods.

Why this question?

Is because 2nd type of pod remain in 'PENDING' state, with an error message:

"0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims."

And, the above error arises inspite of the particular pvs and pvcs are present on the cluster. Explained more here:

https://stackoverflow.com/questions/67585932/why-does-pod-status-remain-pending

-- kkpareek
kubernetes
kubernetes-deployment
kubernetes-pod
persistent-volumes

1 Answer

5/19/2021

There is no difference at all. In a Kubernetes cluster, a Pod is a Pod, however it was created.

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:

  • You are mounting the same PVC on different Pods at the same time, but the Persistent Volume's Access Mode does not support that (see documentation)
  • The PVC you are using for the "Pending" Pod does not have an associated Persistent Volume (there might be several reasons why this happens).
  • 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.

You might get more information by looking at the events of the Pending pod using kubectl describe pod <podname>

-- whites11
Source: StackOverflow