Storage Classes in Kubernetes, Let’s Manage Persistent Data

One essential aspect in Kubernetes is how to handle persistent storage, and this is where Kubernetes Storage Classes come into play. In this article, we’ll explore what Storage Classes are, their key components, and how to use them effectively with practical examples.
If you’re working with applications that need to store data persistently (like databases, file systems, or even just configuration files), you’ll want to understand how these work.

What is a Storage Class?

Imagine you’re running a library (that’s our Kubernetes cluster). Now, you need different types of shelves for different kinds of books, some for heavy encyclopedias, some for delicate rare books, and others for popular paperbacks. In Kubernetes, Storage Classes are like these different types of shelves. They define the types of storage available in your cluster.

Storage Classes allow you to dynamically provision storage resources based on the needs of your applications. It’s like having a librarian who can create the perfect shelf for each book as soon as it arrives.

Key Components of a Storage Class

Let’s break down the main parts of a Storage Class:

1. Provisioner: This is the system that will create the actual storage. It’s like our librarian who creates the shelves.
2. Parameters: These are specific instructions for the provisioner. For example, “Make this shelf extra sturdy” or “This shelf should be fireproof”.
3. Reclaim Policy: This determines what happens to the storage when it’s no longer needed. Do we keep the shelf (Retain) or dismantle it (Delete)?
4. Volume Binding Mode: This decides when the actual storage is created. It’s like choosing between having shelves ready in advance or building them only when a book arrives.

Creating a Storage Class

Now, let’s create our first Storage Class. We’ll use AWS EBS (Elastic Block Store) as an example. Don’t worry if you’re unfamiliar with AWS, the concepts are similar for other cloud providers.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Let’s break this down:

• name: fast-storage: This is the name we’re giving our Storage Class.
• provisioner: ebs.csi.aws.com: This tells Kubernetes to use the AWS EBS CSI driver to create the storage.
• parameters: type: gp3: This specifies that we want to use gp3 EBS volumes, which are a type of fast SSD storage in AWS.
• reclaimPolicy: Delete: This means the storage will be deleted when it’s no longer needed.
• volumeBindingMode: WaitForFirstConsumer: This tells Kubernetes to wait until a Pod actually needs the storage before creating it.

Using a Storage Class

Now that we have our Storage Class, how do we use it? We use it when creating a Persistent Volume Claim (PVC). A PVC is like a request for storage from an application.

Here’s an example of a PVC that uses our Storage Class:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-storage
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-storage
  resources:
    requests:
      storage: 5Gi

Let’s break this down too:

• name: my-app-storage: This is the name of our PVC.
• accessModes: – ReadWriteOnce: This means a single node can mount the storage as read-write.
• storageClassName: fast-storage: This is where we specify which Storage Class to use, it matches the name we gave our Storage Class earlier.
• storage: 5Gi: This is requesting 5 gigabytes of storage.

Real-World Use Case

Let’s imagine we’re running a photo-sharing application. We need fast storage for the database that stores user information and slower, cheaper storage for the actual photos.

We could create two Storage Classes:

1. A “fast-storage” class (like the one we created above) for the database.
2. A “bulk-storage” class for the photos, perhaps using a different type of EBS volume that’s cheaper but slower.

Then, we’d create two PVCs (Persistent Volume Claim), one for each Storage Class. Our database Pod would use the PVC with the “fast-storage” class, while our photo storage Pod would use the PVC with the “bulk-storage” class.

This way, we’re optimizing our storage usage (and costs) based on the needs of different parts of our application.

In Summary

Storage Classes in Kubernetes provide a flexible and powerful way to manage different types of storage for your applications. By understanding and using Storage Classes, you can ensure your applications have the storage they need while keeping your infrastructure efficient and cost-effective.

Whether you’re working with AWS EBS, Google Cloud Persistent Disk, or any other storage backend, Storage Classes are an essential tool in your Kubernetes toolkit.

Tags: CloudStorageDevOpsEBSk8skubernetesPersistentStorageStorageClass