Question 46417 in Debian Question posted in
The oficial documentation can be found here.

Kubernetes Pod mount first container's content into a second container – Debian

I’ve been searching and every answer seems to be the same example (https://kubernetes.io/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/). In a pod you can create an empty volume, then mount that into two containers and any content written in that mount will be seen on each container. While this is fine my use case is slightly different.

Container A
/opt/content

Container B
/data

Container A has an install of about 4G of data. What I would like to do is mount /opt/content into Container B at /content. This way the 4G of data is accessible to Container B at runtime and I don’t have to copy content or specially build Container B.

My question, is this possible. If it is, what would be the proper pod syntax.

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:

  restartPolicy: Never

  volumes:
  - name: shared-data
    emptyDir: {}

  containers:

  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /opt/content

  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /content
Tags:

3

Answers


  1. Chosen as BEST ANSWER
    0

    From my research and testing the best I can tell is within a POD two containers can not see each others file system. The volume mount will allow each container to have a mount created in the pod to the specified path (as the example shows) and then any items written to it after that point, will be seen on both. This works great for logs and stuff.

    In my context, this proves to not be possible and creating this mount, and then having Container A copy the 4G directory to the newly created mount is to time consuming to make this an option.

    Best I can tell is the only way to do this is create a Persistent Volume or other similar and mount that in the Container B. This way Container A contents are stored in the Persistent Volume and it can be easily mounted when needed. The only issue with this is the Persistent Volume will have to be setup in every Kube cluster defined which is the pain point.

    If any of this is wrong and I just didn't find the right document please correct me. I would love to be able to do this.


  2. 0

    Your code example in your question should work. Both are using the same volume and you mount them under different locations in the container.
    nginx-container will have the shared-data content in /opt/content and debian-container will have it in /content.
    With mountPath you specify where the volume should be mounted in the container

    Login or Signup to reply.
  3. 0

    When a container is started, first the container image (or more precisely the layers of an image) are mounted. Afterwards, your custom volumes are mounted, hiding any data from the image at and below the mount path. So sharing data from an image among several containers without copying them is not possible.

    The typical solution is and stays to use an init container which downloads or copies the actual data into an ephemeral volume, which then is shared by one or more other containers (https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container).

    initContainers:
- name: init
  image: <image-containing-the-data-based-on-some-basic-image>
  command: ["sh", "-c", "cp -ar /opt/content/* /mnt/target/"]
  volumeMounts:
  - name: shared-data
    mountPath: /mnt/target

    What you actually would need, is a kind of container storage interface (CSI) driver which supports creating volumes from container images. I found two projects which would exactly do that, but none of them states to be ready for production.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search