<p>I have a simple web app that uses <code>volume</code>/<code>persistent volume claim</code> to serve static data from there. Pods got scheduled only on the first worker node where volume resides.
How to deal with the <code>shared</code> volume between nodes in case I want to scale pods and have them allocated across all the available nodes?</p>
<pre><code>      - name: app-nginx
        image: nginx:1.20.0
        command: [&quot;/usr/sbin/nginx&quot;, &quot;-g&quot;, &quot;daemon off;&quot;]
        volumeMounts:
        - name: static-volume
          mountPath: &quot;/opt/static&quot;

      volumes:
      - name: static-volume
        persistentVolumeClaim:
          claimName: pvc-static
</code></pre>
<p>One option is to use <code>NFS</code> and not physically allocate volume on an EC2 instance.
Another way is to duplicate static files for each pod (populate them into proper directory with init container) but that requires extra time and is not feasible for a lot a static data.</p>
<p>What's the proper way to deal with such a case within Kubernetes? Is there a way to declare deployment which will be using logically same volume but physically different instances located on the different nodes?</p>

<p>What you are looking for is a volume provider that supports the <code>ReadOnlyMany</code>
or <code>ReadWriteMany</code> <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">Access Mode</a>.</p>
<p>Follow the documentation link to get a list of the officially supported ones.</p>
<p>If you are on <code>AWS</code> than probably using <code>EFS</code> through the <code>NFS</code> plugin will be the easiest solution, but please take into account the fact it is an NFS-based solution and you might hit a performance penalty.</p>
<p>As a side note, what you are trying to do smeels like an anti-pattern to me.
Docker images for an application should be self contained. In your case, having a container serving a static website should contain all the static files it needs to in order to be fully portable. This would remove the need to have an external volume with the data completely.</p>
