Introduction

The main reason behind containerization is to allow microservices to run in a stateless way. A container will receive provisioned cloud resources, perform its tasks, and then be destroyed as soon as the process is over. There are no traces of that container or tied up cloud resources to worry about. This was what has made containerization so popular in the first place.

Running microservices as stateless instances, however, is not always as easy as it seems. As more applications get refactored and more microservices rely on containers for efficiency, sticking with the stateless concept becomes harder and harder. Stateless containers don’t always have the ability to meet complex requirements.

Here’s a simple truth: truly stateless applications, those that require no data to be stored over a long period of time, are unicorns; they are incredibly difficult to find in the wild, if not impossible. This is where persistent volumes, or stateful storage, come in handy. It bridges the gap between ideal containerization and the requirements of apps and services.

Kubernetes Persistent Volume

Before we go further into how persistent volumes can be utilized, we need to take a closer look at persistent volume in Kubernetes. Kubernetes has always managed its storage resources in a peculiar way. It provisions, configures, and attaches storage blocks using a specific process or primitive; they must be executed for the volumes to be usable.

Provisioning is the simplest part of the equation. This is the part where Persistent Volumes are created. You have the option to provision volumes statically or dynamically—we will get to this in a bit. Configuration of volumes is handled as Storage Class. Storage Class contains details on the volumes they are associated with.

To complete the process, the volumes need to be attached to pods. Persistent Volume Claims are issued by pods whenever they need to use the storage blocks. A Persistent Volume Claim details the amount of storage required as well as other requirements based on the pods’ operations. Volumes can be attached and detached without being destroyed.

Persistent Volume is slightly different from Ephemeral Volume in one way: the latter exists only for as long as the pods exist. Unlike Persistent Volume, Ephemeral Volume is created during the pod creation process and gets destroyed when the pod is destroyed. It is handy for storing temporary data or for supporting certain operations such as data visualization.

#kubernetes #containers #storage #containers and containerization #persistent storage #persistent volume