<p>I've been looking into kubernetes for docker orchestration and one of my use cases is to have multiple containers spawned on different nodes, and each container needs to have read access to a list of very large files (20G+).</p>

<p>Because the files can be updated at times, we will be use block volume. I'm running the cluster on esxi we are limited to open source and non-cloud solutions...</p>

<p>By reading <a href="https://kubernetes.io/docs/concepts/storage/volumes/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/storage/volumes/</a>, seems like one of the options would be portworx. I'm wondering if there's any other better options out there? </p>

<p>I assume this is a pretty common use case. I'm very new to Kubernetes so any help/advice will be greatly appreciated!</p>

Kevin Yu
<p>First of all on Volumes, there are so many options also depends upon where your cluster is hosted (on prem or managed cloud provider?) managed cloud providers usually would have either their own option of easy mounting their block storage options e.g. Azure storage by Azure, S3 for AWS OR third party driver solutions  and so on but things to know and note here:</p>

<ul>
<li>On Kube volumes, you mentioned - though its outlives container but within Pod and when a Pod ceases to exist, the volume will cease to exist, too. which means you can not use across nodes for diff Pods acorss nodes . This has to be used within specific Pod </li>
<li>In case options available, consider managed cloud provider's default block mount solutions. It would be less painful for integration and also persistence issues</li>
<li>Finally, from design perspective, this seems against microservice/docker/containerization pattern - you may want to revisit your original need and goals as Pods are supposed to be created on the fly and stateless as possible - created and recreated whenever needed if any issues or for scalability need</li>
</ul>

<p>Hope this helps</p>
