Getting Started with Volumes

State preservation#

Having a system without a state is impossible. Even though there is a tendency to develop stateless applications, we still need to deal with the state. There are databases and other stateful third-party applications. No matter what we do, we need to make sure that the state is preserved no matter what happens to containers, Pods, or even whole nodes.

Most of the time, stateful applications store their state on disk. That leaves us with a problem. If a container crashes, kubelet will restart it. The problem is that it will create a new container based on the same image. All data accumulated inside a container that crashed will be lost.

The volumes#

Kubernetes Volumes solve the need to preserve the state across container crashes. In essence, Volumes are references to files and directories made accessible to containers that form a Pod. The significant difference between different types of Kubernetes Volumes is in the way these files and directories are created.

While the primary use-case for Volumes is the preservation of state, there are quite a few others. For example, we might use Volumes to access Docker’s socket running on a host. Or we might use them to access configuration residing in a file on the host file system.

We can describe Volumes as a way to access a file system that might be running on the same host or somewhere else. No matter where that file system is, it is external to the containers that mount volumes. There can be many reasons why someone might mount a Volume, with state preservation being only one of them.

There are over twenty-five Volume types supported by Kubernetes. It would take us too much time to go through all of them. Besides, even if we’d like to do that, many Volume types are specific to a hosting vendor. For example, awsElasticBlockStore works only with AWS, azureDisk and azureFile work only with Azure, and so on and so forth.

We’ll limit our exploration to Volume types that can be used within k3d. You should be able to extrapolate that knowledge to Volume types applicable to your hosting vendor of choice.

The following command will create a cluster. It will copy the prometheus.yml from usercode/volume from the user directory to /files in the cluster.

Troubleshooting tips for minikube#

If you are working with minikube locally, you will also need to copy volume/prometheus-conf.yml file inside the Minikube VM. When it starts, it will copy all the files from ~/.minikube/files on your host, into the /files directory in the VM.

⚠️ Depending on your operating system, the ~/.minikube/files directory might be somewhere else. If that’s the case, please modify the above command accordingly.