According to the documentation here: https://docs.docker.com/storage/volumes/
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.
In other words, the expectation is that, if i have files like so in /var/lib/mysql
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
Then, when I mount a volume into /var/lib/mysql
then all the files from the container should be copied into my volume.
But I find this is not happening:
/var/lib/mysql/mysql # ls
auto.cnf ib_buffer_pool ib_logfile0 ib_logfile1 ibdata1
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.
Note: The Volume in question is actually mounted by kubernetes. So, I'm making a major assumption here that
volumeMounts:
- name: xtz-persistent-storage
mountPath: "/var/lib/mysql/"
is the equivalent of doing this : docker run -p 443:443 --rm -v mysql:/var/lib/mysql <image>
Kubernetes Volumes
is not the same thing as Docker Volumes
.
From the Kubernetes documentation:
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).
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.
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.
So, although the name of the concept is the same, that is a different volume
.
On the mount, Kubernetes overlays a destination directory.
Unfortunately, for now, there are no ways to merge the content in the mounted volume and in the container. Here is one of discussions about it.