<p>Kubernetes creates one PersistentVolume for each VolumeClaimTemplate definition on an statefulset. That makes each statefulset pod have its own storage that is not shared across the replicas. However, I would like to share the same volume across all the statefulset replicas.</p>
<p>It looks like the approach should be the following:</p>
<ol>
<li>Create a PVC on the same namespace.</li>
<li>On the statefulset use Volumes to bound the PVC</li>
<li>Ensure that the PVC is ReadOnlyMany or ReadWriteMany</li>
</ol>
<p>Assuming that my application is able to deal with any concurrency on the shared volume, is there any technical problem if I have one PVC to share the same volume across all statefulset replicas?</p>

<p>I wholeheartedly agree with the comments made by @Jonas and @David Maze:</p>
<blockquote>
<p>You can do this, it should work. There is no need to use volumeClaimTemplates unless your app needs it.</p>
</blockquote>
<blockquote>
<p>Two obvious problems are that ReadWriteMany volumes are actually a little tricky to get (things like AWS EBS volumes are only ReadWriteOnce), and that many things you want to run in StatefulSets (like databases) want exclusive use of their filesystem space and use file locking to enforce this.</p>
</blockquote>
<hr />
<p>Answering on the question:</p>
<blockquote>
<p>Is there any technical problem if I have one PVC to share the same volume across all statefulset replicas?</p>
</blockquote>
<p>I'd say that this would mostly depend on the:</p>
<ul>
<li>How the application would handle such scenario where it's having single PVC (writing concurrency).</li>
<li>Which storage solution are supported by your Kubernetes cluster (or could be implemented).</li>
</ul>
<p>Subjectively speaking, I don't think there should be an issue when above points are acknowledged and aligned with the requirements and configuration that the cluster/applications allows.</p>
<hr />
<p>From the application perspective, there is an inherent lack of the software we are talking about. Each application could behave differently and could require different tuning (look on the David Maze comment).</p>
<p>We do not also know anything about your infrastructure so it could be hard to point you potential issues. From the hardware perspective (Kubernetes cluster), this would inherently go into making a research on the particular storage solution that you would like to use. It could be different from cloud provider to cloud provider as well as on-premise solutions. You would need to check the requirements of your app to align it to the options you have.</p>
<p>Continuing on the matter of <code>Volumes</code>, I'd reckon the one of the important things would be <code>accessModes</code>.</p>
<p>Citing the official docs:</p>
<blockquote>
<h3>Access Modes</h3>
<p>A PersistentVolume can be mounted on a host in any way supported by the resource provider. As shown in the table below, providers will have different capabilities and each PV's access modes are set to the specific modes supported by that particular volume. For example, NFS can support multiple read/write clients, but a specific NFS PV might be exported on the server as read-only. Each PV gets its own set of access modes describing that specific PV's capabilities.</p>
<p>The access modes are:</p>
<ul>
<li>ReadWriteOnce -- the volume can be mounted as read-write by a single node</li>
<li>ReadOnlyMany -- the volume can be mounted read-only by many nodes</li>
<li>ReadWriteMany -- the volume can be mounted as read-write by many nodes</li>
</ul>
<p>In the CLI, the access modes are abbreviated to:</p>
<ul>
<li>RWO - ReadWriteOnce</li>
<li>ROX - ReadOnlyMany</li>
<li>RWX - ReadWriteMany</li>
</ul>
<hr />
<ul>
<li><em><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">Kubernetes.io: Docs: Concepts: Storage: Persistent Volumes: Access modes</a></em></li>
</ul>
</blockquote>
<p>One of the issues you can run into is with the <code>ReadWriteOnce</code> when the <code>PVC</code> is mounted to the <code>Node</code> and <code>sts-X</code> (<code>Pod</code>) is scheduled onto a different <code>Node</code> but from the question, I'd reckon you already know about it.</p>
<hr />
<blockquote>
<p>However, I would like to share the same volume across all the statefulset replicas.</p>
</blockquote>
<p>An example of a <code>StatefulSet</code> with a <code>Volume</code> that would be shared across all of the replicas could be following (modified example from Kubernetes documentation):</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: &quot;nginx&quot;
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
          name: web
      # VOLUME START 
        volumeMounts:
        - name: example-pvc
          mountPath: /usr/share/nginx/html
      volumes:
       - name: example-pvc
         persistentVolumeClaim:
           claimName: pvc-for-sts
      # VOLUME END 
</code></pre>
<hr />
<p>Additional resources:</p>
<ul>
<li><em><a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">Kubernetes.io: Docs: Concepts: Workloads: Controllers: Statefulset</a></em></li>
<li><em><a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/" rel="nofollow noreferrer">Kubernetes.io: Docs: Concepts: Storage: Persistent Volumes</a></em></li>
</ul>
