<blockquote>
<p>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).</p>
</blockquote>
<p>I'm not entirely sure what you mean here. When you use a <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/" rel="nofollow noreferrer">PersistentVolumeClaim</a> to request a volume from Kubernetes, you specify the name of the claim. You don't directly specify the name of the <code>PersistentVolume</code> that will be created by the <code>PersistentVolumeClaim</code>, but that's okay: you mount the volume via the claim.</p>
<p>That is, if I have:</p>
<pre><code>apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pgsql-data
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 80Gi
</code></pre>
<p>Then I can mount this in a pod like this:</p>
<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: postgres
    image: docker.io/postgres:14
  volumes:
    - name: psql-data
      persistentVolumeClaim:
        claimName: psql-data
</code></pre>
<p>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.</p>

CC BY-SA 4.0
2022-07-19T21:22:21.227Z
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
CC BY-SA 4.0
2022-07-19T21:22:48.383Z
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
CC BY-SA 4.0
2022-07-19T23:33:49.520Z
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
CC BY-SA 4.0
2022-07-20T20:11:06.080Z
@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
CC BY-SA 4.0
2022-07-19T01:02:50.887Z
2022-07-19T01:02:50.887Z
larsks
<p>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.</p>
<p>The two Kubernetes storage options I am seeing each have a limitation:</p>
<p><strong>Dynamic Storage:</strong> 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).</p>
<p><strong>Static Storage:</strong> You have to manually make the folder structure that the Persistent Volume expects.</p>
<p>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:</p>
<p><strong>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)?</strong></p>
<p>OR</p>
<p><strong>Is there a way to have a manually created Persistent Volume create the needed folder structure given in the yaml?</strong>  (This is perferred.)</p>

<kubernetes>
Setup Folder When Setting up Kubernetes Storage
Vaccano
# Setup Folder When Setting up Kubernetes Storage

(Asked by: username_0 on 2022-07-18)

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)?**

OR

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

**Tags:** kubernetes


---

## 1 answers

### Answer by username_1 on 2022-07-19. Score: 0

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
metadata:
  name: pgsql-data
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 80Gi

Then I can mount this in a pod like this:
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: postgres
    image: docker.io/postgres:14
  volumes:
    - name: psql-data
      persistentVolumeClaim:
        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.

> **Comments:**
> **username_0**: 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.  
> **username_0**: 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).  
> **username_1**: 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.  
> **username_0**: @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.  

---

