A Crash Course in Persistent Kubernetes Storage

Application containers such as Docker containers are well known for their ability to provide true application portability and easy scalability. As organizations expanded their adoption of containers, however, storage became increasingly problematic. Today, the Kubernetes orchestration platform eases many of the storage issues related to early container implementations, especially when it comes to persistent Kubernetes storage.

Early on, containers were suitable only for stateless applications because they lacked any sort of persistent storage. Containers worked really well as a platform for hosting front end Web applications, for example, but they were not suitable for hosting things like database applications or anything else that required persistent storage.

Today, this is no longer an issue, thanks to the open source Kubernetes, which has become an industry standard for container management. One of the nice things about Kubernetes is that it fully supports both stateful applications and persistent storage.

If an organization wants to use persistent Kubernetes storage, there are two high-level tasks that must be performed. First, the Kubernetes cluster must be attached to a physical storage device. Second, the hosted application must be given access to the storage.

The Container Storage Interface is the mechanism that is used to connect a storage device to a Kubernetes cluster. While it is possible to attach a Kubernetes container to a storage device without using the Container Storage Interface, the Container Storage Interface provides better overall security, as well as the ability to use storage drivers without having to hard code them into Kubernetes.

Kubernetes exposes persistent storage to hosted applications through the use of persistent volumes (which are sometimes referred to as PVs). In many ways, a persistent volume really isn’t all that different from the volumes that are used by virtual machines. Like a virtual machine volume, a persistent volume is created to be a specific size. For instance, a persistent volume might be 500 GB in size. Similarly, persistent volumes are formatted with a file system, and they are identified by a name and a volume ID.

Another way that Kubernetes persistent volumes are similar to virtual machine volumes is how they are provisioned. Every hypervisor has its own way of doing things, but most hypervisors allow virtual hard disks to be created independently of virtual machines. An administrator might, for example, create several virtual hard disks and then connect those virtual hard disks to a few pre-existing virtual machines later on.

A similar approach can be used for provisioning Kubernetes persistent volumes. Often it is the administrator who creates Kubernetes persistent volumes. There are, however, mechanisms for creating volumes dynamically through an automated process.

Once created, a persistent volume is essentially an isolated object. At this point in the process, the persistent volume does not have a relationship with any other Kubernetes objects, such as applications or pods. The reason for this has to do with the requirement for volume persistence.

In a Kubernetes environment, containers run in pods. A single pod can accommodate one or more containers. Like a virtual machine, pods are provisioned with resources such as an IP address and storage. One of the big differences between pods and virtual machines, however, is that pods tend to have relatively short lifespans. When a pod is deleted, the pod’s storage volume is also deleted. That’s why persistent storage is created outside of the pod structure. Persistent storage volumes are not tied to a pod’s lifespan. Even if you delete a pod, any persistent storage volumes that the pod was using will remain in place until an administrator deletes them.

Because persistent storage volumes reside outside of the pod structure, there has to be a mechanism for linking a pod to a persistent storage volume. This linking is accomplished through a persistent volume claim. A persistent volume claim (which is sometimes abbreviated as PVC) can be made either manually or dynamically, and makes a persistent storage volume available for use by a pod.

One more storage object that you should know about is the storage class. Imagine that you have a containerized application that needs access to a persistent volume. As an administrator, you could manually initiate the persistent volume claim, or you could orchestrate the process. Now imagine that you want to automate the creation of the application container so that authorized users can create application instances on an as-needed basis. You don’t know exactly how many copies of the containerized application will be created, but you do know that each copy is going to need its own persistent storage.

In a situation like this, you can use a storage class to help keep things organized. A storage class is simply a collection of persistent volumes that are similar to one another. A persistent volume claim can be designed so that claims are made against a particular storage class, thereby ensuring that the application gets the persistent storage that it needs.

More specific details can be found in the Kubernetes documentation.