<p>Let's say I deployed 2 pods to Kubernetes and they both have the same underlying image which includes some read-only file system.</p>
<p>By default, do the pods share this file system? Or each pod copies the file system and hence has a separate copy of it?</p>
<p>I would appreciate any answer and especially would love to see some documentation or resources I can read in order to delve deeper into this issue.</p>
<p>Thanks in advance!</p>

Yaya
<p>In short, it depends on where the pods are running. If they are running on the same node, then yes, they share the same <strong>read-only</strong> copy of the image, and if on separate nodes, then they have their own <strong>read-only</strong> copy of the image. Keep reading if you are interesting in knowing more technical details of this.</p>
<h2>Inside Kubernetes Pods</h2>
<p>A pod can be viewed as a set of containers bound together. It is a construct provided by Kubernetes to be able to have certain benefits out of the box. We can understand your question better if we zoom into a single node that is part of a Kubernetes cluster.</p>
<p>This node will have a <code>kubelet</code> binary running on it, which will receive certain &quot;instructions&quot; from the <code>api-server</code> on running pods. These &quot;instructions&quot; will be passed onto the <code>cri</code> (Container Runtime Interface) running on your node (let's assume it is the <code>docker-engine</code>). And this <code>cri</code> will be responsible for actually running the needed containers and report back to the <code>kubelet</code> which will report back to the <code>api-server</code> ultimately reporting to the <code>pod-controller</code> that the pod containers are <code>Running</code>.</p>
<p>Now, the question becomes, do multiple pods share the same image? I said the answer is <strong>yes</strong> for pods on the same node and this is how it works.</p>
<ol>
<li>Say you run the first pod, the <code>docker</code> daemon running on your k8s node pulls this image from the configured registry and stores it in the local cache of the node. It then starts a container using this image. Note that a container that runs, utilizes the image as simply a <strong>read-only</strong> file-system, and depending on the storage driver configured in <code>docker</code>, you can have a &quot;writeable layer&quot; on top of this <strong>read-only</strong> filesystem that is used to allow you to read/write on the file-system of your container. This writeable layer is temporary and vanishes when you delete the container.</li>
<li>When you run the second pod, the daemon finds that the image is already available locally, and simply creates the small writeable layer for your container, on top of an existing image from the cache and provides this as a &quot;writeable file system&quot; to your container. This speeds things up.</li>
</ol>
<p>Now, in case of docker, these <strong>read-only</strong> layers of the image (as one 'file-system') are <em>shared across all containers</em> running on the host. This makes sense since there is no need to copy a read-only file system and sharing it with multiple containers is safe. And each container can maintain its <em>uniqueness</em> by storing its data in the thin writeable layer that it has.</p>
<h2>References</h2>
<p>For further reading, you can use:</p>
<ol>
<li>Read about <a href="https://docs.docker.com/storage/storagedriver/" rel="nofollow noreferrer">storage drivers</a> in docker. It explains how multiple containers share the r/o layer of the image.</li>
<li>Read details about <a href="https://docs.docker.com/storage/storagedriver/select-storage-driver/" rel="nofollow noreferrer">different storage driver types</a> to see how this &quot;thin writeable layer&quot; is implemented in practice by <code>docker</code>.</li>
<li>Read about <a href="https://kubernetes.io/docs/setup/production-environment/container-runtimes/" rel="nofollow noreferrer">container runtimes</a> in Kubernetes to understand that <code>docker</code> isn't the only supported runtime. There are others but more or less, the same will hold true for them as well, as it makes sense to cache images locally and re-use the read-only image file system for multiple containers.</li>
<li>Read more about the <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/" rel="nofollow noreferrer">kubelet</a> component of Kubernetes to understand how it can support multiple run-times and how it helps the <code>pod-controller</code> setup and manage containers.</li>
<li>And of course, finally you can find more details about pods <a href="https://kubernetes.io/docs/concepts/workloads/pods/" rel="nofollow noreferrer">here</a>. This will make a lot more sense after you've read the material above.</li>
</ol>
<p>Hope this helps!</p>
