Day 27/#30daysofK8s

All files related to docker storage are stored under /var/lib/docker.

There are 2 layers when it comes to docker — 1) Image Layer and, 2) Container Layer.

The image layer is what happens when the image is built from the Dockerfile and the commands written in it are executed. Every time a change is made to the Dockerfile and the image is rebuilt, not all the commands are executed. Only the commands to which change has been made and the commands after that are executed, all the layers before that are taken from cache so to enhance the performance. This layer maintains persistency when it comes to storage.

Container layer — is what happens once the container is up and the things that happen after it. Anything executed within the container will only survive as long as the container survives. This data is volatile. And hence by default, the storage is non-persistent.

To make the container layer persistent, we can create docker volumes within — docker volume create <vol_name> and then use this volume while running a container like —
docker run -v <vol_name>:/var/lib/docker/<location> <img_name>

In case we don’t create a volume explicitly, docker will automatically create one when we run the docker run command. This whole thing is called as volume mounting.

In case we already have a volume created and want to use it, then passing the path_to_volume instead of <vol_name> in the docker run command will do the trick(i.e. bind mounting).

The new way to do the mounting is the following —

docker run <image_name> --mount type=bind,source=<path_to_vol>,target=/var/lib/docker/<location>

This whole thing happens with the help of storage drivers. Commonly know storage drivers are — AUFS, Device Mapper, Overlay, Overlay2, ZFS, BTRFS. Docker automatically chooses the best driver based on the host OS. Every driver has it’s own performance and stability characteristics, so it can be chosen based on the application.

Volume drivers are used to manage volumes which is not the same as storage drivers. Volume drivers also help store data in cloud along with storing it locally.

Earlier K8s was developed to work only with docker, but as new container runtime emerged, K8s was forced to develop an interface to support them all and hence Container Runtime Interface came into existence.

Along with CRI, Container Network Interface(CNI) and Container Storage Interface(CSI) came into existence to support all the network and storage systems in existence.

These interfaces are not specific to K8s, but a universal system that allows any container runtime, network and storage to work with any container orchestration tool, given they(the trio) have implemented these interfaces.

Volume management in K8s —

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /opt
      name: data-volume
volumes:
- name: data-volume
  hostPath:
    path: /data
    type: Directory

If the container goes down, it’s data still remains in the hostPath.path

The above configuration works well if it’s a single node cluster, but in case of multi node cluster, nodes on different servers expect to use the same data storage but can’t because the storage is different for all the servers. In such case, K8s advises the use of external storage systems such as GlusterFS, AWS, Ceph, ScaleIO, GCE, Azure, Flocker…

If for eg we use AWS, we can define the volumes section like —

...
volumes:
- name: aws-volume
  awsElasticBlockStore:
    volumeID: <volume-id>
    type: ext4