Kubernetes 101 – Volumes

This is the fourth in a series of blog posts that will explain the different components of Kubernetes. Primarily because if I can explain it here, I’ll have learned it quite well myself.

The first part is about Pods and can be found here.
The second part is about Controllers and can be found here.
The third part is about Services and can be found here.

Where does the data go?

Kubernetes was originally planned to be for stateless applications to be deployed. So when the pod died, or was killed, the data went with it. In fact it’s a little more granular than that, when a container starts it has an exact copy of the filesystem of the image it is built from. So if a container within a pod is restarted, anything written to that filesystem is gone. Or if two containers are running inside the same pod, they have logically separate filesystems so can’t share data.

This is where volumes come in. What follows is an overview of your options with regard to volumes.

What is a volume?

A volume is a component of a pod and can’t be defined as a separate object in Kubernetes. As it is defined at the pod level, it persists across individual container restarts. It can also be mounted into the filesystem of any of the containers in each pod. When defining your volume, you also define the type of volume. Typically if you want to share semi-persistent data between two containers in the same pod you’re going to use one of the below:

Configuration Volumes

Other types that could be used to pass configuration information into a pod are listed below. These will be the subject of a separate blog post in the future.

Persistent Volumes

What to do if you want to maintain a central repository of files on the network for your application to access, like static website content? Or run a database like MySQL? Or a stateful cache like redis or memcached? I.e. you want a truly persistent chunk of storage that persists across pod & node restarts.
If you’re on a public cloud vendor, you’re likely to have options around their block storage providor:

Dynamically Provisioning Persistent Volumes

Wouldn’t you just know it, you can! With the use of the Cloud Storage Interface (CSI) you can hook into whatever cloud provider you’re running on and initiate a request for a volume. Simply install the cloud provider’s controllers and custom resource types and all this extra functionality is exposed to be consumed by whoever needs it. All the cluster administrator needs to create at this point is a storageClass object (or as many as are required) and let whoever is deploying applications know of it’s existence. If they really don’t get on, the deployment person can query the API server for available classes or the cluster administrator could nominate one of the classes as the default.
Once this is done, a persistentVolumeClaim can be created and a volume matching the storageClass and volume size will be created.


There’s no shortage of options with volumes on Kubernetes. It’s more about ensuring that you’re using the right type and are managing them correctly. Anything that can be completed automatically by your platform can only make your life easier!