<p>I am new to Kubernetes but familiar with docker.</p>
<h3>Docker Use Case</h3>
<p>Usually, when I want to persist data I just create a volume with a name then attach it to the container, and even when I stop it then start another one with the same image I can see the data persisting.
So this is what i used to do in docker</p>
<pre class="lang-sh prettyprint-override"><code>docker volume create nginx-storage
run -it --rm -v nginx-storage:/usr/share/nginx/html -p 80:80 nginx:1.14.2
</code></pre>
<p>then I:</p>
<ol>
<li><strong>Create a new html file in /usr/share/nginx/html</strong></li>
<li><strong>Stop container</strong></li>
<li><strong>Run the same docker run command again (will create another container with same volume)</strong></li>
<li><strong>html file exists (which means data persisted in that volume)</strong></li>
</ol>
<h3>Kubernetes Use Case</h3>
<p>Usually, when I work with Kubernetes volumes I specify a PVC (PersistentVolumeClaim) and PV (PersistentVolume) using hostPath which will bind mount directory or a file from the host machine to the container.</p>
<p>what I want to do is reproduce the same behavior specified in the previous example (<strong>Docker Use Case</strong>) so how can I do that? Is Kubernetes creating volumes process is different from Docker? and if possible providing a YAML file would help me understand.</p>

Affes Salem
<p>To a first approximation, you can't (portably) do this.  Build your content into the image instead.</p>
<p>There are two big practical problems, especially if you're running a production-oriented system on a cloud-hosted Kubernetes:</p>
<ol>
<li><p>If you look at the <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes" rel="nofollow noreferrer">list of PersistentVolume types</a>, very few of them can be used in ReadWriteMany mode.  It's very easy to get, say, an AWSElasticBlockStore volume that can only be used on one node at a time, and something like this will probably be the default cluster setup.  That means you'll have trouble running multiple pod replicas serving the same (static) data.</p>
</li>
<li><p>Once you do get a volume, it's very hard to edit its contents.  Consider the aforementioned EBS volume: you can't edit it without being logged into the node on which it's mounted, which means finding the node, convincing your security team that you can have root access over your entire cluster, enabling remote logins, and then editing the file.  That's not something that's actually possible in most non-developer Kubernetes setups.</p>
</li>
</ol>
<p>The thing you should do instead is build your static content into a custom image.  An image registry of some sort is all but required to run Kubernetes and you can push this static content server into the same registry as your application code.</p>
<pre class="lang-sh prettyprint-override"><code>FROM nginx:1.14.2
COPY . /usr/share/nginx/html
# Base image has a working CMD, no need to repeat it
</code></pre>
<p>Then in your deployment spec, set <code>image: registry.example.com/nginx-frontend:20220209</code> or whatever you've chosen to name this build of this image, and do not use volumes at all.  You'd deploy this the same way you deploy other parts of your application; you could use Helm or Kustomize to simplify the update process.</p>
<p>Correspondingly, in the plain-Docker case, I'd avoid volumes here.  You don't discuss how files get into the <code>nginx-storage</code> named volume; if you're using imperative commands like <code>docker cp</code> or debugging tools like <code>docker exec</code>, those approaches are hard to script and are intrinsically local to the system they're running on.  It's not easy to copy a Docker volume from one place to another.  Images, though, can be pushed and pulled through a registry.</p>
