Managing Persistent Volumes in Deployment☸️

Welcome back to our DevOps journey!

In my previous blog post, we delved into the intricacies of "Mastering ConfigMaps and Secrets in Kubernetes". I hope you found that information valuable as we continue our exploration of Kubernetes best practices. If you haven't had a chance to read it yet, I highly recommend you check it out.

In this blog, we'll learn persistent storage and also learn how to manage Persistent Volumes in your deployments effectively.

What are Persistent Volumes in Kubernetes?

A Persistent Volume (PV) stands as a foundational resource, representing as a distinct storage unit within the cluster. Not tethered to any particular Pod or application, Persistent Volumes are orchestrated and overseen by cluster administrators through YAML or JSON configuration files.

Key Characteristics of Persistent Volumes

Persistence: As the name suggests, PVs are persistent; PVs exist until explicitly deleted, regardless of whether any Pod is using them. They persist across Pod restarts.
Capacity: PVs have a specified amount of storage capacity.
Access Modes: PVs offer versatility through various access modes, including:
- ReadWriteOnce (allowing mounting as read-write by a single node)
- ReadOnlyMany (permitting read-only mounting by multiple nodes)
- ReadWriteMany (enabling read-write mounting by multiple nodes)
Reclaim Policy: Administrators can specify what happens to the data on the PV when the associated claim is deleted. Common policies include "Retain," "Delete," and "Recycle."

What are Persistent Volume Claims?

A Persistent Volume Claim (PVC) is a request for storage by a user. It allows users to consume abstract storage resources without having to understand the details about how that storage is provided. It's user-friendly storage consumption.

Key Characteristics of Persistent Volume Claims

Dynamic Provisioning: PVCs can be dynamically provisioned if no matching PV with the required specifications is found. Kubernetes will automatically create a suitable PV if dynamic provisioning is enabled for the storage class.
```
   kubectl create -f pvc.yaml
```
Access Modes: Similar to PVs, PVCs also have access modes, ensuring the requested storage matches the application's requirements.
Binding: PVCs bind to suitable PVs based on their requirements, establishing a connection between the user's storage needs and the cluster's available resources (e.g., capacity, access mode, storage class).
Lifecycle Bound to Pods: The existence of PVCs is intimately connected to the Pods utilizing them. If a Pod is deleted or scaled down, the associated PVC is set free. When the final Pod using a particular PVC is deleted, the PVC itself might either be retained (subject to the PV's reclaim policy) or deleted.

How Persistent Volumes and Persistent Volume Claims Work Together

Understanding how PVs and PVCs interact is crucial for efficient storage management in Kubernetes. When a Pod needs storage, it creates a PVC.

The PVC then binds to an available PV that satisfies its requirements. The Pod can now use the PV as a volume.

Cluster administrators create PVs to provide storage resources within the cluster.
Application developers or users generate PVCs, specifying their storage needs.
Kubernetes manages the binding process, linking each PVC to an appropriate PV.
Monitoring the binding status is achievable through relevant commands.
```
   kubectl get pvc
```
Pods can reference PVCs in their configurations, enabling seamless utilization of the associated storage.

Commands for Managing Persistent Volumes

Let's explore some essential commands to interact with Persistent Volumes and Persistent Volume Claims:

List Persistent Volumes:
```
  kubectl get pv
```
List Persistent Volume Claims:
```
  kubectl get pvc
```
Describe Persistent Volume:
```
  kubectl describe pv <pv-name>
```
Describe Persistent Volume Claim:
```
  kubectl describe pvc <pvc-name>
```

You read more about Persistent Volumes on the official Kubernetes website.

Task 01: Adding a Persistent Volume to Your Deployment

In this task, we'll walk through the process of adding a Persistent Volume to your deployment.

Ensure you have a running Kubernetes cluster and follow these steps in your development environment.

Create a Persistent Volume (pv.yaml)
- We have a storage component within our cluster that can be dynamically provisioned and claimed by a Pod.
- To initiate the creation of a Persistent Volume, we utilize a file located on our node.
- We can craft a YAML file, named pv.yaml, outlining the specifications of the Persistent Volume.
- This file must encompass details such as storage size, access modes, and the node file path.

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: pv-django-todo-app
    spec:
      capacity:
        storage: 1Gi
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      hostPath:
        path: "/mnt/data"

In this YAML file, a PV is defined with a 1Gi capacity, ReadWriteOnce access mode, and a hostPath specifying the location for storing the data.

Execute the following command to apply the pv.yaml file
```
 kubectl apply -f pv.yaml -n <namespace-name>
```
Create a Persistent Volume Claim (pvc.yaml)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-todo-app
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Mi

The PVC YAML file outlines a PVC labeled "pvc-todo-app" that requests 500Mi of storage.

Execute the following command to apply the pvc.yaml file
```
 kubectl apply -f pvc.yml -n <namespace-name>
```
Update the Deployment file deployment.yml

After creating the PV and PVC, update the deployment.yml file to include the Persistent Volume Claim. Confirm that it appropriately points to the recently generated PVC.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: todo-app-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: todo-app
  template:
    metadata:
      labels:
        app: todo-app
    spec:
      containers:
        - name: todo-app
          image: nikhilraut/todo-app
          ports:
            - containerPort: 8000
          volumeMounts:
            - name: todo-app-data
              mountPath: /app
      volumes:
        - name: todo-app-data
          persistentVolumeClaim:
            claimName: pvc-todo-app

Execute the following command to apply the deployment.yaml file
```
 kubectl apply -f deployment.yml -n <namespace-name>
```
Verify the creation of the Persistent Volume and Persistent Volume Claim by inspecting the status of pods within your designated namespace.
```
 kubectl get pods -n < namespace-name >
 kubectl get pv -n < namespace-name >
```

Task 02: Accessing Data in the Persistent Volume

With the integration of your Persistent Volume into the Deployment, let's explore how you can retrieve the data stored within it.

Access a Pod in your Deployment using the command:
```
 kubectl exec -it <pod-name> -- /bin/bash
```
In this step, we can generate a file within the pod and inspect the data in the Persistent Volume through the interactive shell.
```
 cd /tmp/app
```
Conclude by exiting the pod. Confirm your ability to access the data stored in the Persistent Volume from within the Pod by examining the contents of the file you created during the Pod session.

Conclusion

In conclusion, Managing Persistent Volumes in your Kubernetes deployment is a critical aspect of ensuring data persistence and reliability. By understanding the concepts of Persistent Volumes and Persistent Volume Claims, you empower yourself to design robust and scalable storage solutions for your applications.

I hope this blog has been insightful. Feel free to connect with me on LinkedIn to share your thoughts, ask questions, or discuss further about Kubernetes, DevOps, and more.

I invite you to connect with me on LinkedIn linkedin.com/in/gaurav-gawande-profile for engaging discussions on Kubernetes, DevOps, and all things related.