<p>I'm starting to learn Kubernetes recently and I've noticed that among the various tutorials online there's almost no mention of Volumes. Tutorials cover Pods, ReplicaSets, Deployments, and Services - but they usually end there with some example microservice app built using a combination of those four. When it comes to databases they simply deploy a pod with the &quot;mongo&quot; image, give it a name and a service so that other pods can see it, and leave it at that. There's no discussion of how the data is written to disk.</p>
<p>Because of this I'm left to assume that with no additional configuration, containers are allowed to write files to disk. I don't believe this implies files are persistent across container restarts, but if I wrote a simple NodeJS application like so:</p>
<pre><code>const fs = require(&quot;fs&quot;);
fs.writeFileSync(&quot;test.txt&quot;, &quot;blah&quot;);
const value = fs.readFileSync(&quot;test.txt&quot;, &quot;utf8&quot;);
console.log(value);
</code></pre>
<p>I suspect this would properly output &quot;blah&quot; and not crash due to an inability to write to disk (note that I haven't tested this because, as I'm still learning Kubernetes, I haven't gotten to the point where I know how to put my own custom images in my cluster yet -- I've only loaded images already on Docker Hub so far)</p>
<p>When reading up on <a href="https://kubernetes.io/docs/concepts/storage/volumes/" rel="nofollow noreferrer">Kubernetes Volumes</a>, however, I came upon the <a href="https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/" rel="nofollow noreferrer">Ephemeral Volume</a> -- a volume that:</p>
<blockquote>
<p>get[s] created and deleted along with the Pod</p>
</blockquote>
<p>The existence of ephemeral volumes leads me to one of two conclusions:</p>
<ul>
<li>Containers <em><strong>can't</strong></em> write to disk without being granted permission (via a Volume), and so every tutorial I've seen so far is bunk because mongo will crash when you try to store data</li>
<li>Ephemeral volumes make no sense because you can <em><strong>already</strong></em> write to disk without them, so what purpose do they serve?</li>
</ul>
<p>So what's up with these things? Why would someone create an ephemeral volume?</p>

<p>Container processes can always write to the container-local filesystem (Unix permissions permitting); but any content that goes there will be lost as soon as the pod is deleted.  Pods can be deleted fairly routinely (if you need to upgrade the image, for example) or outside your control (if the node it was on is terminated).</p>
<p>In the documentation, the <a href="https://kubernetes.io/docs/concepts/storage/ephemeral-volumes/#types-of-ephemeral-volumes" rel="nofollow noreferrer">types of ephemeral volumes</a> highlight two major things:</p>
<ol>
<li><a href="https://kubernetes.io/docs/concepts/storage/volumes/#emptydir" rel="nofollow noreferrer">emptyDir</a> volumes, which are generally used to share content between containers in a single pod (and more specifically to publish data from an init container to the main container); and</li>
<li>injecting data from a <a href="https://kubernetes.io/docs/concepts/storage/volumes/#configmap" rel="nofollow noreferrer">configMap</a>, the <a href="https://kubernetes.io/docs/concepts/storage/volumes/#downwardapi" rel="nofollow noreferrer">downward API</a>, or another data source that might be totally artificial</li>
</ol>
<p>In both of these cases the data &quot;acts like a volume&quot;: you specify where it comes from, and where it gets mounted, and it hides any content that was in the underlying image.  The underlying storage happens to not be persistent if a pod is deleted and recreated, unlike persistent volumes.</p>
<p>Generally prepackaged versions of databases (like <a href="https://helm.sh/" rel="nofollow noreferrer">Helm</a> charts) will include a persistent volume claim (or create one per replica in a stateful set), so that data <em>does</em> get persisted even if the pod gets destroyed.</p>
