<p>According to the documentation here:
<a href="https://docs.docker.com/storage/volumes/" rel="nofollow noreferrer">https://docs.docker.com/storage/volumes/</a></p>

<blockquote>
  <p>If you start a container which creates a new volume, as above, and the container has files or directories in the directory to be mounted (such as /app/ above), the directory’s contents are copied into the volume. The container then mounts and uses the volume, and other containers which use the volume also have access to the pre-populated content.</p>
</blockquote>

<p>In other words, the expectation is that, if i have files like so in /var/lib/mysql</p>

<pre><code>root@d8fa9a8b305a:/var/lib/mysql# ls
auto.cnf         xtz           ib_logfile0  ibdata1  mysql               sys
debian-5.7.flag  ib_buffer_pool  ib_logfile1  ibtmp1   performance_schema
</code></pre>

<p>Then, when I mount a volume into <code>/var/lib/mysql</code> then all the files from the container should be copied into my volume.</p>

<p>But I find this is not happening:</p>

<pre><code>/var/lib/mysql/mysql # ls
auto.cnf        ib_buffer_pool  ib_logfile0     ib_logfile1     ibdata1
</code></pre>

<p>This is content of the volume that I mounted into /var/lib/mysql, and as you can see the data is not the same as the one present in /var/lib/mysql of the docker image itself. So, as a result, there's a failure on startup.</p>

<p><strong>Note</strong>: The Volume in question is actually mounted by kubernetes. So, I'm making a major assumption here that </p>

<pre><code>volumeMounts:
        - name: xtz-persistent-storage
          mountPath: "/var/lib/mysql/"
</code></pre>

<p>is the equivalent of doing this : <code>docker run -p 443:443 --rm -v mysql:/var/lib/mysql &lt;image&gt;</code></p>

<p>Kubernetes <code>Volumes</code> is not the same thing as Docker <code>Volumes</code>.</p>
<p>From the Kubernetes <a href="https://kubernetes.io/docs/concepts/storage/volumes/" rel="nofollow noreferrer">documentation</a>:</p>
<blockquote>
<p>Docker also has a concept of volumes, though it is somewhat looser and less managed. In Docker, a volume is simply a directory on disk or in another container. Lifetimes are not managed and until very recently there were only local-disk-backed volumes. Docker now provides volume drivers, but the functionality is very limited for now (e.g. as of Docker 1.7 only one volume driver is allowed per container and there is no way to pass parameters to volumes).</p>
<p>A Kubernetes volume, on the other hand, has an explicit lifetime - the same as the pod that encloses it. Consequently, a volume outlives any containers that run within the Pod, and data is preserved across Container restarts. Of course, when a Pod ceases to exist, the volume will cease to exist, too. Perhaps more importantly than this, Kubernetes supports many types of volumes, and a Pod can use any number of them simultaneously.</p>
<p>At its core, a volume is just a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the medium that backs it, and the contents of it are determined by the particular volume type used.</p>
</blockquote>
<p>So, although the name of the concept is the same, that is a different <code>volume</code>.</p>
<p>On the mount, Kubernetes overlays a destination directory.</p>
<p>Unfortunately, for now, there are no ways to merge the content in the mounted volume and in the container. Here is one of <a href="https://groups.google.com/forum/#!topic/kubernetes-dev/muq5KIwOcNo" rel="nofollow noreferrer">discussions</a> about it.</p>
