<p>I want to build an application/service which uses a static application data which can get updated over time. Currently, I implemented this by having both the application and the data within the same container. However, this requires redeployment when either application or data change. I want to separate the app and data volume implementation so that I can update the application and the data independently, meaning I won't have to rebuild the application layer when the application data is updated and vice versa.</p>

<p>Here are the characteristics of the Application Data and its Usage:</p>

<ul>
<li>Data is <strong>not frequently updated</strong>, but <strong>read very frequently</strong> by the application</li>
<li>Data is not a database, it's a collection of <strong>file objects</strong> with size ranging from 100MB to 4GB which is initially stored in a cloud storage</li>
<li>Data stored in the cloud storage serves as a single source of truth for the application data</li>
<li>The application will <strong>only read</strong> from the Data. The process of updating data in cloud storage is an external process outside the application scope.</li>
</ul>

<p>So here, we are interested in sync-ing the data in cloud storage to the volume in Kubernetes deployment. What's the best way to achieve this objective in Kubernetes?</p>

<p>I have several options in mind:</p>

<ol>
<li><p>Using one app container in one deployment, in which the app will also include the logic for data loading and update which pulls data 
from cloud storage to the container --> simple but tightly coupled with the storage read-write implementation</p></li>
<li><p>Using the cloud store directly from the app --> this doesn't require container volume, but I was concerned with the huge file size because the app is an interactive service which requires a quick response</p></li>
<li><p>Using two containers in one deployment sharing the same volume --> allow great flexibility for the storage read-write implementation</p>

<ul>
<li>one container for application service reading from the shared volume</li>
<li>one container for updating data and listening to update data request which writes data to the shared volume --> this process will pull data from cloud storage to the shared volume</li>
</ul></li>
<li><p>Using one container with a Persistent Disk</p>

<ul>
<li>an external process which writes to the persistent disk (not sure how to do this yet with cloud storage/file objects, need to find a way to sync gcs to persistent disk)</li>
<li>one container for application service which reads from the mounted volume</li>
</ul></li>
<li><p>Using Fuse mounts</p>

<ul>
<li>an external process which writes to cloud storage</li>
<li>a container which uses fuse mounts</li>
</ul></li>
</ol>

<p>I am currently leaning towards option 3, but I am not sure if it's the common practice of achieving my objective. Please let me know if you have better solutions.</p>

dekauliya
<p>Yes. 3. is the most common option but make sure you use an <a href="https://kubernetes.io/docs/concepts/workloads/pods/init-containers/" rel="nofollow noreferrer">initContainer</a> to copy the data from your cloud storage to a local volume. That local volume could be any of the <a href="https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes" rel="nofollow noreferrer">types</a> supported by Kubernetes.</p>
