How Kubernetes Persistent Volume Claims Work

At its most basic level, there are three Kubernetes classes required for persistent volumes: A pod, a persistent volume claim, and the persistent volume itself. A pod requests a volume claim, then mounts it to a local directory. The claim points to a persistent volume, asking for a specific amount of its resources. That’s it in a nutshell.

But we do not live in nutshells, we live in real life — so we need a bit more of an explanation! Let’s delve into what a persistent volume claim actually is, and why we need it.

Want to Learn Kubernetes?

If you’re a network administrator or engineer, it’s worth learning about — and how to use — Kubernetes. If you’re new to Kubernetes, CBT Nuggets can help you get up to speed. You can choose from a variety of Kubernetes training from Trevor Sullivan. 

His Kubernetes courses are designed to help learners build the foundation they need to really leverage Kubernetes for their organizations. Start your free week today.

Why Do We Need Persistent Volumes?

It’s important to know that pods are ephemeral. This means that the pod that holds your application can be deleted (i.e, killed) at a moment’s notice. This is a feature, not a bug. By allowing pods to be ephemeral, they can be replicated, scaled, and redeployed following a specific blueprint. In fact, this is a core feature of Infrastructure as a Service.

Now, let’s take a step back. If pods are ephemeral how can data be stored on them? After all, the data will naturally be deleted when the pod ceases to exist. This is the exact problem persistent volumes solve.

A persistent volume is a Kubernetes class that provides data storage services to a pod. Notice the word, persistent. This means it will stay alive regardless of which pod is using it — or whether that pod even exists. 

How Do You Use a Persistent Volume in Kubernetes?

Say you are hosting a web application that sells shoes. You want your application to be reliable, scalable, and easily configurable. So of course, Kubernetes is the way to go. However, you still need to figure out how to store your user’s data. Your application is replicated between five pods that can be deleted without warning. Having them on a pod would be untenable. So instead, you have each pod point to a persistent volume. That would look a lot like this:

apiVersion:v1

kind:Pod

metadata:

  name:shoes-r-us

spec:

  containers:

    - name:frontend

      image:nginx

      volumeMounts:

      - mountPath:"/var/www/html"

        name:my-user-data

  accessModes:

    - ReadWriteOnce

  volumes:

    - name:my-user-data

      persistentVolumeClaim:

        claimName:my-persistent-volume-claim

Now the frontend of the shoe store is pointing to a persistent volume claim called my-user-data. Then we are mounting that volume at the path “var/www/html”. This concept is a little difficult to wrap your head around at first, but once you write it out a couple of times, everything will fall into place. Notice that that pod is not actually pointing to a persistent volume, but only a claim to one. Let’s talk about that.

What is a Persistent Volume Claim?

A persistent volume claim is similar to the pod-node relationship. A pod consumes the resources of a node, and a persistent volume claim consumes the resources of a volume. Then, a user takes a slice of the persistent volume’s resource. It looks something like this:

apiVersion:v1

kind:PersistentVolumeClaim

metadata:

  name:my-persistent-volume-claim

spec:

  accessModes:

    - ReadWriteOnce

  volumeMode:Filesystem

  resources:

    requests:

      storage:2Gi

In this example, we are creating a claim called my-persistent-volume-claim. Please scroll back up to the pod definition file and you will notice that they are the same. These names have to match exactly for the pod to use the resource. It is requesting 2Gi of memory. That means our online shoe store has a max of 2 gigabytes. 

What is a Persistent Volume in Kubernetes?

A persistent volume is a completely independent database that can be used by any number of pods. The key though is that it’s never accessed itself — only through claims. Let’s look at how one is actually defined to get a clearer picture.

apiVersion:v1

kind:PersistentVolume

metadata:

  name:my-persistent-volume

spec:

  capacity:

    storage:10Gi

  accessModes:

    - ReadWriteOnce

It may be apparent here that we are not specifically pointing the volume to any particular claim, or vice versa. That is because when a persistent volume and claim are created, Kubernetes will automatically scan persistent volumes to find one to bind to a persistent volume claim. However, it is possible to tell a persistent volume claim to specially use a particular volume.

Final Thoughts 

In this article, we discussed how a pod leverages a persistent volume to save data. The biggest takeaway is this: a volume and its data lives on regardless of any pod’s status. This allows you to easily dismount a volume from one deployment and add it to another. By decoupling the data from the application, Kubernetes created a remarkably flexible framework.