<p>I need some clarification about Storage concepts in Kubernetes. Suppose we have <code>PodA</code> with one container <code>containerA</code>.</p>
<ol>
<li><p>Running containerA implies the usage/creation of a filesystem. Is this filesystem loaded into memory? <strong>Does it require memory resources or storage resources</strong>?</p>
</li>
<li><p>When using a volume (e.g PersistentVolumeClaim/ConfigMap/Secret) we have to mount it to the container:</p>
<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
    - name: redis-secret
      mountPath: /data/secret
  volumes:
  - name: redis-storage
    persistentVolumeClaim:
      claimName: pvc-name 
  - name: redis-secret
    secret:
      secretName: secret-name
</code></pre>
<p>But, <em><strong>what exactly mounting to the container means</strong></em>? Again, does this have to do with memory or actual storage? What if we have a PV(Persistent volume) that refers to a big DB? Should that require actual space storage?</p>
</li>
</ol>

Unknown developer
<ol>
<li><p>The filesystem is usually not mounted into memory as this would be way too overkill most of the time, because essentially it would just be a ramdisk type of volume. You can check the types of storages supported by Kubernetes <a href="https://kubernetes.io/docs/concepts/storage/volumes/#volume-types" rel="nofollow noreferrer">here</a> as it gives you a nice idea what kind of volumes there are and how they work. Note, there are lot of different volume types like <strong>nfs</strong> for example, where the whole filesystem will get mounted over the network, so neither memory ressources or storage ressources are affected much on the local machine (except for caching purposes obviously).</p>
</li>
<li><p>Mount basically means the same as the usual mount on unix type of systems does in general, but lets go through your example:</p>
<ul>
<li><strong>spec.containers.volumeMounts</strong>: This means that you essentially mount the path <strong>/data/redis</strong> in the container and specify the volume for that mount: <strong>redis-storage</strong>. This volume however has not yet been created, so we need to do that later on. Volumes and VolumeMounts in Kubernetes go hand in hand, you cannot create a volume without mounting it or mount a volume that has not been created yet.</li>
<li><strong>spec.volumes</strong>: Here you declare your volumes. In your first example, you have created a volume named <strong>redis-storage</strong> that will use a <strong>persistentVolumeClaim</strong> with the claimName <strong>pvc-name</strong>. What this really means is that Kubernetes will look for a <strong>persistentVolumeClaim</strong> ressource with that name and try to bound to it. That persistentVolumeClaim then will look for a <strong>persistentVolume</strong> it will try to <strong>claim</strong>. If that succeeds, i.e there is a free <strong>persistentVolume</strong> ressource that matches the claims requirements, it will <strong>bound</strong> to it. After that, you have created a volumeMount from the containers <strong>data/redis</strong> directory to the persistent volume. If that persistent volume is of type hostPath for example, the mount will be on the local machine itself where you have specified it (see <a href="https://kubernetes.io/docs/concepts/storage/volumes/#hostpath" rel="nofollow noreferrer">here</a> for an example, but if you know Docker volumes think of it as /var/lib/docker).</li>
</ul>
</li>
</ol>
<p>The other volumes you mentioned like <strong>secret</strong> or <strong>configMap</strong> are ressources in the cluster and are namespace bound objects. They have special use cases and I really recommend you to look into the docs for an explanation of them, as they are quite easy to understand. Think of a configMap as a &quot;file&quot; that lies in a namespace in the cluster that can be mounted by a pod in the same namespace and contains configuration data. Great example would be a <strong>php.ini</strong> or other configuration files that need to be loaded at container startup and need simultaneously need to be persistent. A secret has the use case of storing sensitive data in the cluster, for example database passwords or TLS certificates. An example would be a mysql-password secret that would contain the password for the root user, so if a mysql pod terminates and restarts it would mount that secret and regain the password as otherwise the database wouldn't startup anymore.</p>
<p>If you create a mysql pod for example and a volume that mounts <strong>/var/lib/mysql</strong> with a persistentVolumeClaim that will claim to a hostPath type of persistentVolume, the <strong>/var/lib/mysql</strong> folder from the container will lie somewhere on the host machine and therefore would eat up disk space. If you would be using nfs for example and therefore mount a network drive, the database would still be persistent as you mounted <strong>/var/lib/mysql</strong> to that network drive, but it wouldn't consume any disk space on the host machine (except for cached data obviously).</p>
<p>Hope I could clear some things up for you :)</p>
