Demystifying Storage in Kubernetes: A Beginner's Guide

Introduction: Welcome to the world of Kubernetes, where managing storage for your applications can sometimes feel like navigating a maze. In this article, we'll unravel the complexities of storage in Kubernetes by exploring four key concepts: Persistent Volume (PV), Persistent Volume Claim (PVC), Storage Class (SC), and Container Storage Interface (CSI). Whether you're a beginner or a seasoned Kubernetes user, understanding these concepts is crucial for efficiently managing your applications.

1. Understanding Persistent Volume (PV): Imagine Persistent Volumes (PVs) as neatly organized storage units within your Kubernetes cluster. These storage units exist independently of any specific Pod and can be provisioned either statically or dynamically. When a Pod needs storage, it can claim a PV, much like renting a storage unit for your belongings.

2. Decoding Persistent Volume Claim (PVC): Persistent Volume Claims (PVCs) are requests for storage made by Pods or users. Think of PVCs as the paperwork you fill out to rent a storage unit. Once a PVC is created, Kubernetes matches it with an appropriate PV, binding the two together. This binding allows Pods to access the storage defined by the PV.

3. Exploring Storage Class (SC): Storage Classes (SCs) are resource types in Kubernetes that help you dynamically provision PVs (storage). As soon as a pod claims a PV, it will create the storage for you. Now, where does it get the actual storage? It can be from the public cloud, private cloud, or Kubernetes nodes themselves.

4. Unveiling Container Storage Interface (CSI): The Container Storage Interface (CSI) acts like a universal translator for storage systems and Kubernetes. It standardizes how Kubernetes interacts with external storage systems, enabling seamless integration and management. With CSI, Kubernetes can communicate with a wide range of storage solutions without needing bespoke integrations. Each CSI requires a driver program or provisioner known as a CSI provisioner, which allows CSI to connect to external storage units. In this article, I will show you how to install the EBS CSI driver.

Thanks, Vimal Daga for Below Explanation.

5. Practical Implementation in Kubernetes (K8s) Cluster on EKS:

Now that we've demystified PV, PVC, SC, and CSI, let's put our knowledge into practice. Below are the steps to implement these concepts in a Kubernetes cluster running on Amazon EKS:

1. Installing EBS CSI Driver or Provisioner that will associated with SC to tell the type of Storage.
2. Define Storage Classes to specify the types of storage available.
3. Issue Persistent Volume Claims to request storage for Pods.
4. Deploy Pods that consume the storage defined by PVCs.

Installing the EBS CSI Driver: The AWS Elastic Block Store (EBS) Container Storage Interface (CSI) driver enables Kubernetes clusters to dynamically provision and manage EBS volumes. Follow these steps to install the EBS CSI driver on your Kubernetes cluster:

• Attaching IAM Roles to AKS for Accessing AWS EBS - Go to IAM Service look out for Role Attach to EKS and attach Policy ( Permission ) to access EBS.

Here I am giving EC2 full access because EBS is part of EC2 Service.

• Download and apply the EBS CSI Driver YAML Manifest: EBS CSI Driver

Defining Storage Class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
parameters:
   type: gp2
volumeBindingMode: WaitForFirstConsumer        

Let's break down each part:

• apiVersion: Specifies the version of the Kubernetes API being used.
• kind: Specifies the kind of resource, which in this case is StorageClass.
• metadata: Contains metadata about the SC, such as its name.name: The name of the SC, which is fast in this example.
• provisioner: Specifies the provisioner used to dynamically provision volumes for this SC. In this example, ebs.csi.aws.com is used, which provisions AWS Elastic Block Store (EBS) volumes.
• parameters: Specifies additional parameters specific to the provisioner. In this example, the type parameter is set to gp2, which indicates the General Purpose SSD (gp2) EBS volume type on AWS.
• reclaimPolicy: Specifies what happens to the PVs created by this SC when the associated PVCs are deleted. Possible values are Retain, Delete, or Recycle.In this example, Retain is used, meaning the PVs are not deleted automatically when PVCs are deleted, allowing manual cleanup.
• allowVolumeExpansion: Specifies whether volume expansion is allowed for PVCs created using this SC.If set to true, PVCs can be resized if the underlying storage supports it.
• volumeBindingMode: This field specifies how PVs should be dynamically provisioned and bound to PVCs. There are two possible values for
• Immediate: With volumeBindingMode: Immediate, a PV is dynamically provisioned and bound to a PVC as soon as the PVC is created. This means that the volume is provisioned and bound right away, without waiting for a Pod to request it. This mode is useful when you want to ensure that the volume is available immediately, even if it's not yet being used.
• WaitForFirstConsumer: With volumeBindingMode: WaitForFirstConsumer, a PV is dynamically provisioned when a Pod using the PVC is scheduled onto a node. The PV is then bound to the PVC at that time. This mode defers the provisioning and binding of the volume until it's actually needed by a Pod. It's useful for scenarios where you want to conserve resources and only provision storage when it's required by a Pod.

Defining PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 4Gi        

The main argument in pvc is to tell to storage class name and accessModes - Let's talk about access modes here-

• If your application needs read-write access and can only run on one node at a time, use ReadWriteOnce.
• If your application only needs read access and can be mounted by multiple nodes, use ReadOnlyMany.
• If your application needs read-write access and must be mounted by multiple nodes, use ReadWriteMany (if your storage solution supports it).

Defining Pod that claims for Storage:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: centos
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim
        

By following these steps, you'll effectively manage storage for your applications in Kubernetes.

Conclusion: In conclusion, understanding storage in Kubernetes doesn't have to be daunting. By grasping the concepts of PV, PVC, SC, and CSI, you'll be better equipped to manage storage resources efficiently in your Kubernetes clusters. Whether you're running applications on-premises or in the cloud, mastering these concepts will help you build resilient and scalable infrastructure.

Final Thoughts: As you embark on your Kubernetes journey, don't hesitate to experiment with different storage configurations and solutions. Each application has unique requirements, and Kubernetes offers a flexible framework to meet those needs. Happy Kuberneting!