I am trying to setup automation around my Kubernetes storage and hitting some problems. I thought I would ask if there is a solution for this in the community.

The two Kubernetes storage options I am seeing each have a limitation:

Dynamic Storage: You can't control the name of the Persistent Volume nor the directory that it creates on disk (making it hard to connect to again if needed).

Static Storage: You have to manually make the folder structure that the Persistent Volume expects.

Both of these can be overcome with more work. But I find it hard to believe that I am the first person with this issue, so I thought I would ask:

Is there a way using dynamic storage (aka Storage Classes) to choose the Persistent Volume name and folder structure that is created (so it can be re-connected to)?


Is there a way to have a manually created Persistent Volume create the needed folder structure given in the yaml? (This is perferred.)

1 Answer 1


You can't control the name of the Persistent Volume nor the directory that it creates on disk (making it hard to connect to again if needed).

I'm not entirely sure what you mean here. When you use a PersistentVolumeClaim to request a volume from Kubernetes, you specify the name of the claim. You don't directly specify the name of the PersistentVolume that will be created by the PersistentVolumeClaim, but that's okay: you mount the volume via the claim.

That is, if I have:

apiVersion: v1
kind: PersistentVolumeClaim
  name: pgsql-data
  - ReadWriteOnce
      storage: 80Gi

Then I can mount this in a pod like this:

apiVersion: v1
kind: Pod
  name: example-pod
  - name: postgres
    image: docker.io/postgres:14
    - name: psql-data
        claimName: psql-data

Kubernetes doesn't care about the folder structure on the volume; once the volume is mounted, your application can create whatever folder structure it wants.

  • Part 1: When you use a Persistent Volume Claim you can do it two different ways. One way is the "Dynamic" way. You do this by specifying a storage class (or use the default storage class by not specifying a persistent volume) then when it stores it on disk it will make a pseudo random directory to store it all in (It also makes a Persistent Volume that referees to the pseudo random directory. This is the part that you can't control. Then when you mount it on the pod, it puts all the folders/files that your application creates in that pseudo random named folder.
    – Vaccano
    Jul 19, 2022 at 21:22
  • Part 2: But this dynamic creation of Persistent Volumes and folders makes it hard to reconnect to that location on disk if you have to recreate your namespace (or something similar).
    – Vaccano
    Jul 19, 2022 at 21:22
  • Both of those statements are incorrect. Kubernetes does not "make a pseudo random directory to store it all in"; your storage may not even come from the local machine. It could be an NFS share, and RBD volume, etc. And he important part is that you don't care where it comes from or what it's called. It's not hard to reconnect to the storage; if you delete the pod and create it a new one, it will connect to the same storage as long as you use the same volume claim.
    – larsks
    Jul 19, 2022 at 23:33
  • @larks - In the scenario that I am referring to is an NFS share. And the pseudo random directory is created on the NFS share. (Again only when using a storage class). If you think about it, it would have to do this. If it did not, then if there are two separate volume claims on the same storage class and they both tried to save the file "index.html" they would conflict with each other. And when I am talking about "reconnecting" I am meaning if the dynamically created persistent volume and the manually created persistent volume claim are deleted/lost.
    – Vaccano
    Jul 20, 2022 at 20:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.