<p>What I am aiming for is a folder(pod name) per pod created inside of a volume using a volumeClaimsTemplate in a StatefulSet.</p>
<p>An example would be:</p>
<ul>
<li>PersistentVolume = &quot;/data&quot;</li>
<li>Pods:
<ul>
<li>pod-0 = &quot;/data/pod-0&quot;</li>
<li>pod-1 = &quot;/data/pod-1&quot;</li>
</ul>
</li>
</ul>
<p>I am struggling with getting the replicas to create new folders for themselves. Any help with how to do this would be grateful.</p>

StackDrenny
<blockquote>
<p><code>volumeClaimTemplates</code> is a list of claims that pods are allowed to
reference. The StatefulSet controller is responsible for mapping
network identities to claims in a way that maintains the identity of a
pod. Every claim in this list must have at least one matching (by
name) volumeMount in one container in the template. A claim in this
list takes precedence over any volumes in the template, with the same
name.</p>
</blockquote>
<p>This means that with <code>volumeClaimTemplates</code> you can request the PVC from the storage class dynamically.</p>
<p>If we use this <code>yaml</code> as an example:</p>
<pre><code>volumeClaimTemplates: 
  - metadata: 
      name: www
    spec: 
      accessModes: [&quot;ReadWriteOnce&quot;]
      storageClassName: &quot;standard&quot;
      resources: 
        requests: 
          storage: 1Gi
      
</code></pre>
<p>Once you deploy your pods you notice that your pods are being created and <code>PVC</code> is requested during the creation. <code>PVC</code> is name in the following convention:</p>
<p><code>volumeClaimTemplate</code> name + <code>Pod-name</code> + <code>Ordinal-number</code></p>
<p>So if you take above yaml as an example you will receive three PVC (assuming 3 replicas):</p>
<pre><code>NAME        STATUS      VOLUME      
www-web-0   Bound       pvc-12d77135...
www-web-1   Bound       pvc-08724947...
www-web-2   Bound       pvc-50ac9f96
</code></pre>
<p>It's worth mentioning that <code>Persistent Volume Claims</code> represent the exclusive usage of a Persistent Volume by a particular Pod.
This means that if we look into the volumes individually we find that each is assign to a particular pod:</p>
<pre><code>➜ ~ pwd
/tmp/hostpath-provisioner/pvc-08724947...
➜ ~ ls 
web-1
➜ ~ pwd
/tmp/hostpath-provisioner/pvc-50ac9f96...
➜ ~ ls 
web-2
</code></pre>
<hr />
<p>While testing this I did achieve your goal but I had to create <code>persistentvolumes</code> manually and they had to point towards the same local path:</p>
<pre><code> local:
    path: /home/docker/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - minikube
</code></pre>
<p>This combined with <code>subPathExpr</code> mounted the directories named after the pods into the specified path.</p>
<pre><code>    volumeMounts:
    - name: www
      mountPath: /usr/share/nginx/html
      subPathExpr: $(NAME)
    env:
      - name: NAME
        valueFrom: 
          fieldRef:
             fieldPath: metadata.name
</code></pre>
<p>And the result of this (<code>web</code> was the name of the deployment):</p>
<pre><code>➜ ~ pwd
/home/docker/data
➜ ~ pwd
web-0  web-1  web-2
</code></pre>
<p>Here`s more information how  <a href="https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath-with-expanded-environment-variables" rel="nofollow noreferrer">subpath with expanded env variables</a> works.</p>
<blockquote>
<p>Use the <code>subPathExpr</code> field to construct <code>subPath</code> directory names from Downward API environment variables. This feature requires the <code>VolumeSubpathEnvExpansion</code>  <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/" rel="nofollow noreferrer">feature gate</a> to be enabled. It is enabled by default starting with Kubernetes 1.15. The <code>subPath</code> and <code>subPathExpr</code> properties are mutually exclusive.</p>
</blockquote>
<p>Let me know if you have any questions.</p>
