Kubernetes; How a volume is mounted to a container

Question

I need some clarification about Storage concepts in Kubernetes. Suppose we have PodA with one container containerA.

1. Running containerA implies the usage/creation of a filesystem. Is this filesystem loaded into memory? Does it require memory resources or storage resources?

2. When using a volume (e.g PersistentVolumeClaim/ConfigMap/Secret) we have to mount it to the container:

   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
   

   But, what exactly mounting to the container means? 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?

Answer 1

1. 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 here 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 nfs 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).

2. Mount basically means the same as the usual mount on unix type of systems does in general, but lets go through your example:

   • spec.containers.volumeMounts: This means that you essentially mount the path /data/redis in the container and specify the volume for that mount: redis-storage. 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.
   • spec.volumes: Here you declare your volumes. In your first example, you have created a volume named redis-storage that will use a persistentVolumeClaim with the claimName pvc-name. What this really means is that Kubernetes will look for a persistentVolumeClaim ressource with that name and try to bound to it. That persistentVolumeClaim then will look for a persistentVolume it will try to claim. If that succeeds, i.e there is a free persistentVolume ressource that matches the claims requirements, it will bound to it. After that, you have created a volumeMount from the containers data/redis 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 here for an example, but if you know Docker volumes think of it as /var/lib/docker).

The other volumes you mentioned like secret or configMap 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 "file" 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 php.ini 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.

If you create a mysql pod for example and a volume that mounts /var/lib/mysql with a persistentVolumeClaim that will claim to a hostPath type of persistentVolume, the /var/lib/mysql 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 /var/lib/mysql to that network drive, but it wouldn't consume any disk space on the host machine (except for cached data obviously).

Hope I could clear some things up for you :)