<p>I cannot find any information about the priority of data sources when attaching persistent storage to a pod.
It could be that my image already contains some data in a directory that I'm about to have persistent storage mounted to. What happens in such a situation?</p>
<p>In Docker, it is the following:</p>
<ul>
<li>with bind mounts the content of the host directory takes precedence</li>
<li>with volume mounts the container content takes precedence (although I'm not sure what will happen if both the volume and container contain data).</li>
</ul>
<p>Is there any documentation about that for Kubernetes? Ideally, I'd like there to be an option/flag to specify which data source should take precedence. I.e., if I want the image data to take precedence, the mounted volume data would be cleaned and the image data would be put there during the mount process.</p>

mnj
<p>The mounted content <em>always</em> takes precedence over what was in the image.  This works the same way as the standard Unix <strong>mount</strong>(8) command: anything that happened to be at that mount point before is hidden.  This is true in plain Linux, in Docker for all kinds of volume mounts, and in Kubernetes for all kinds of volume mounts.</p>
<p>Docker named volumes have something that looks like an exception.  If you start a container, and try to mount an empty named volume over a directory that contains content in the image, Docker will copy the contents of the image to the volume.  This <em>only</em> happens using native Docker (not Kubernetes), it <em>only</em> happens using named volumes (not bind mounts), and it <em>only</em> happens if the volume is empty.  Volumes are not a general pass-through to the underlying image!  This results in issues like &quot;Docker ignores changes in my Node <code>package.json</code> file&quot; or &quot;my Nginx proxy is serving an old version of my static content&quot;, because once there is content in the named volume it will always take precedence.</p>
<p>If you need to get initial content into a volume, your container needs to know to do that at startup time.  Typically you'd do this with an entrypoint script that does whatever initial setup is required, and then does <code>exec &quot;$@&quot;</code> to run the main container command.  If you can run a command like a database <code>initdb</code> to create an empty skeleton file structure that works, or you can <code>cp -a</code> content from a directory that is not hidden by a volume mount.  If there is already content in the target volume directory it's up to your entrypoint script to figure out how to reconcile that.</p>
<pre class="lang-sh prettyprint-override"><code>#!/bin/sh
# entrypoint.sh

# Copy content into the `/data` directory if necessary
if [ ! -f /data/any-file.txt ]; then
  cp -a /app/data /data
fi

# Launch the main container command
exec &quot;$@&quot;
</code></pre>
<pre class="lang-sh prettyprint-override"><code># Dockerfile
ENTRYPOINT [&quot;/app/entrypoint.sh&quot;] # must be JSON-array form
CMD [&quot;/app/my-app&quot;] # as before
</code></pre>
<p>I'd recommend trying this setup using a Docker host-filesystem bind mount.  This does not have the Docker copy-on-first-use setup, and so if it works correctly with a Docker bind mount it should work in all environments, including Kubernetes.  This also has the advantage of being easy to look at to double-check the right things show up in the mounted directory.</p>
