Sharing non-persistent volume between containers in a pod - kubernetes

Question

I am trying to put two nodejs applications into the same pod, because normally they should sit in the same machine, and are unfortunately heavily coupled together in such a way that each of them is looking for the folder of the other (pos/app.js needs /pos-service, and pos-service/app.js needs /pos)
In the end, the folder is supposed to contain:
/pos
/pos-service
Their volume doesn't need to be persistent, so I tried sharing their volumes with an emptyDir like the following:
apiVersion: apps/v1
kind: Deployment
metadata:
name: pos-deployment
labels:
app: pos
spec:
replicas: 1
selector:
matchLabels:
app: pos
template:
metadata:
labels:
app: pos
spec:
volumes:
- name: shared-data
emptyDir: {}
containers:
- name: pos-service
image: pos-service:0.0.1
volumeMounts:
- name: shared-data
mountPath: /pos-service
- name: pos
image: pos:0.0.3
volumeMounts:
- name: shared-data
mountPath: /pos
However, when the pod is launched, and I exec into each of the containers, they still seem to be isolated and eachother's folders can't be seen
I would appereciate any help, thanks

Answer 1

This is a Community Wiki answer so feel free to edit it and add any additional details you consider important.
Since this issue has already been solved or rather clarified as in fact there is nothing to be solved here, let's post a Community Wiki answer as it's partially based on comments of a few different users.
As Matt and David Maze have already mentioned, it works as expected and in your example there is nothing that copies any content to your emptyDir volume:
With just the YAML you've shown, nothing ever copies anything into the
emptyDir volume, unless the images' startup knows to do that. – David
Maze Dec 28 '20 at 12:45
And as the name itselt may suggest, emptyDir comes totally empty, so it's your task to pre-populate it with the desired data. It can be done with the init container by temporarily mounting your emptyDir to a different mount point e.g. /mnt/my-epmty-dir and copying the content of specific directory or directories already present in your container e.g. /pos and /pos-service as in your example and then mounting it again to the desired location. Take a look at this example, presented in one of my older answers as it can be done in the very same way. Your Deployment may look as follows:
apiVersion: apps/v1
kind: Deployment
metadata:
name: pos-deployment
labels:
app: pos
spec:
replicas: 1
selector:
matchLabels:
app: pos
template:
metadata:
labels:
app: pos
spec:
volumes:
- name: shared-data
emptyDir: {}
initContainers:
- name: pre-populate-empty-dir-1
image: pos-service:0.0.1
command: ['sh', '-c', 'cp -a /pos-service/* /mnt/empty-dir-content/']
volumeMounts:
- name: shared-data
mountPath: "/mnt/empty-dir-content/"
- name: pre-populate-empty-dir-2
image: pos:0.0.3
command: ['sh', '-c', 'cp -a /pos/* /mnt/empty-dir-content/']
volumeMounts:
- name: shared-data
mountPath: "/mnt/empty-dir-content/"
containers:
- name: pos-service
image: pos-service:0.0.1
volumeMounts:
- name: shared-data
mountPath: /pos-service
- name: pos
image: pos:0.0.3
volumeMounts:
- name: shared-data
mountPath: /pos
It's worth mentioning that there is nothing surprising here as it is exacly how mount works on Linux or other nix-based operating systems.
If you have e.g. /var/log/your-app on your main disk, populated with logs and then you mount a new, empty disk defining as its mountpoint /var/log/your-app, you won't see any content there. It won't be deleted from its original location on your main disc, it will simply become unavailable as in this location now you've mounted completely different volume (which happens to be empty or may have totally different content). When you unmount and visit your /var/log/your-app again, you'll see its original content. I hope it's all clear.