In a previous article here, we discuss how there are no rules when it comes to configuring Kubernetes Storage. It is more about understanding the most efficient storage setup for your application and configuring the environment to match the level of efficiency you are aiming for. The wealth of options available today, however, can make that simple process more overwhelming, which is why we’re going to discuss Persistent Volumes here.
Kubernetes is not for everyone when it comes to managing storage, but it does come with options like Persistent Volumes to bridge the gap between the fragile storage of pods and the traditional storage-related problems devs used to experience. If you dig deeper, Persistent Volumes are two objects: Persistent Volume and Persistent Volume Claims.
Persistent Volumes at Work
The first element is Persistent Volume, which is the storage allocated to your cluster. Thanks to Kubernetes’ nature, even assigned storage is platform- and host-agnostic.
Persistent Volumes (PVs) are assigned to a cluster on a near-permanent basis. Unless it is intentionally removed, Kubernetes persistent volumes will continue storing your data. That same data can be used by multiple pods, as long as they have access to the primary Persistent Volume.
Even PVs have two types to choose from. If you have predetermined storage for your apps, then you are using static volumes. Static volume is the easiest one to produce for obvious reasons. You basically assign a certain amount of storage as a resource and you are all set.
Dynamic volumes become more challenging. Dynamic volumes don’t have to be around all the time. It is designed as a flexible alternative to static volumes. New volumes can be acquired and used almost immediately when there is a challenge to solve.
The same dynamic volumes can be removed—it doesn’t need to exist all the time—once you are done with the volumes. This is the way forward to Kubernetes storage. Using StorageClass, you can define the parameters of the storage allocation.
Efficiency is inherently realized given the nature of the Storage Classes and the dynamic allocation. For instance, in the ability for a pod to allocate a portion of storage without waiting on an Administrator to statically pre-allocate the storage first on demand.
Storage Provisioners
Since v1.8, Kubernetes supports a wide range of storage provisioners. Those on AWS EKS can use the provisioner ‘kubernetes.io/aws-ebs’, which allocates an AWS EBS volume for their Kubernetes clusters for example. There are other provisioners too, for example, if you are in GPC, you can use ‘kubernetes.io/gce-pd’ which allocates a GCP Persistent Disk.
Parameters for persistent volumes are defined at two levels: during provisioning and in pod configurations. The latter lets you be more flexible with how persistent volumes are mounted and used. For instance, you can set the access mode of your persistent volumes to ReadWriteMany, making it available to multiple Pods at the same time—though this depends on the volume features. Not all the storage provider supports this mode.
The only catch is that Pods need to be configured the same way. You cannot expect your cluster to work when some Pods use ReadWriteOnce and others use ReadWriteMany, even when they should work logically. Different pods have different volume needs. Those volumes might be supported by different storage providers, which offer different capabilities. So, we can have pods using one volume that supports ReadWriteOnce (typically for local storage), while others use another volume that supports ReadWriteMany (typically storage shared across all the nodes of the cluster). Persistent Volumes require consistency on both levels.
Using Temporary Storage
The introduction of Persistent Volumes made a lot of people even happier with Kubernetes, but using temporary storage for swap and cache is more appropriate. Ephemeral storage, commonly used for storing computational data and temporary data streams, is more suitable if you are looking for short-term solutions. Pods have their own allocated storage, but using ephemeral storage has its benefits.
Kubernetes Storage is more about using storage solutions for the right purpose. Container file system follows the lifespan of the container. Pods have storage that is destroyed when they reach the end of their lifestyle, a volume. Do you see what I’m getting at?
The Specific Lifetime of Kubernetes Volumes
Unlike Docker volumes, Kubernetes volumes have an explicit lifetime—which is the same as the pod that encloses it. Even a Persistent Volume gets destroyed when the cluster is destroyed. Different volumes are simply assigned on different levels, which means each storage type needs to be managed differently.
There are ways to automate volumes management, to simplify the process of dynamically assigning storage, and to create a complex storage structure. This would be with the use of proper and different Storage Classes. You can also go the simple route, use dynamic volumes to your advantage, and scale up without running into issues around architectural components. For example, how complex the architecture is, the number of pods claiming volumes, the different quality of service each volume offers or a given pod’s needs, etc.
The latter is the better option of the two. Dig deep into your storage requirements and add a Persistent Volume to your cluster only when it is necessary.
Caylent provides a critical DevOps-as-a-Service function to high growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.
