Persistent Volumes and Claims in Kubernetes: Complete Guide

Persistent Volumes and Claims in Kubernetes: A Complete Guide

Kubernetes is known for its robust container orchestration capabilities. One key feature that makes it powerful is the use of Persistent Volumes (PV) and Persistent Volume Claims (PVC). These resources provide a way to manage storage in a Kubernetes cluster, enabling containers to access shared storage with persistence even after pods are terminated.

In this guide, we’ll explore how to create and manage Persistent Volumes and Persistent Volume Claims in Kubernetes. You’ll also learn best practices for integrating these resources into your Kubernetes workflows. If you need expert assistance, ZippyOPS offers consulting and managed services in DevOps, DataOps, Cloud, and Infrastructure, ensuring your Kubernetes environment is optimized and secure.

Kubernetes Persistent Volumes and Claims setup example

What Are Persistent Volumes and Claims in Kubernetes?

In Kubernetes, a Persistent Volume (PV) is a piece of network storage that is provisioned by an administrator. Unlike traditional Docker volumes that are tied to the lifecycle of a pod, Kubernetes volumes, including PVs, remain intact even if the pod is terminated. This ensures that data is not lost when pods are restarted or rescheduled.

A Persistent Volume Claim (PVC) is a request for storage that a user can make. The claim is processed by Kubernetes, which then binds it to an available PV that meets the requested requirements. A PVC abstracts the underlying storage, so the user doesn’t need to worry about how the storage is provisioned.

Key Differences Between Docker and Kubernetes Volumes

While both Docker and Kubernetes support volumes, Kubernetes provides more flexibility. In Docker, volumes are limited to the lifespan of a pod. However, Kubernetes volumes are not bound to any single pod and can be shared across multiple containers within a pod. Kubernetes also supports several types of storage, including cloud storage and network file systems, allowing pods to use multiple storage types simultaneously.

Types of Volumes in Kubernetes

Kubernetes supports several types of volumes, each serving different purposes. Some common types include:

NFS (Network File System): This allows a pod to mount a remote file system over the network, enabling shared access across multiple pods.
EmptyDir: A temporary directory that stores data for the lifespan of a pod. It’s useful for storing scratch data.
ConfigMap: Mounts configuration data directly into a pod.
Persistent Volume: A managed storage resource that persists even after a pod is deleted.

You can use multiple volumes simultaneously in a pod, depending on the needs of your application.

How to Create a Persistent Volume in Kubernetes

Creating a Persistent Volume in Kubernetes involves defining its properties, such as storage capacity, access modes, and the underlying storage path. Below is an example of a YAML configuration to create a Persistent Volume.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

In this configuration:

name: Specifies the name of the Persistent Volume (pv0001).
storage: Defines the capacity (10Gi in this case).
accessModes: Specifies the access mode (ReadWriteOnce means the volume can be mounted as read-write by a single node).
nfs: Defines the network file system, with the path and server details.

After creating the YAML file, apply it using the following command:

kubectl create -f Persistent-Volume.yaml

You can then verify the Persistent Volume creation by running:

kubectl get pv

Understanding Persistent Volume Claims (PVC)

A Persistent Volume Claim (PVC) is a request for storage in Kubernetes. PVCs are linked to specific Persistent Volumes, and once a claim is created, Kubernetes will automatically bind it to an available PV that satisfies the requirements.

Here’s an example YAML configuration for a Persistent Volume Claim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim-1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

This claim requests a storage capacity of 3Gi with the access mode ReadWriteOnce. To create the PVC, use the following command:

kubectl create -f PersistentVolumeClaim.yaml

To check the PVC status:

kubectl get pvc

Kubernetes will bind the PVC to the appropriate Persistent Volume, ensuring that the pod has access to the requested storage.

Using PV and PVC with a Pod

Once a Persistent Volume and Persistent Volume Claim are created, you can use them in your pods. Below is an example YAML configuration for a pod that uses the myclaim-1 PVC:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim-1

In this configuration:

volumeMounts: Specifies the mount path within the container where the volume will be mounted.
volumes: Defines the volume to be used, which is the PVC named myclaim-1.

To create the pod:

kubectl create -f pv-pvc.yaml

You can check the pod’s status by running:

kubectl get pods

Once the pod is running, it will have access to the persistent storage as defined by the PVC.

Cleaning Up Persistent Volumes and Claims

When you’re done using the Persistent Volume and Persistent Volume Claim, you can delete them with the following commands:

Delete the PVC:

kubectl delete pvc myclaim-1

Delete the PV:

kubectl delete pv pv0001

This will remove both the claim and the volume from the cluster.

Conclusion

Understanding how to work with Persistent Volumes and Persistent Volume Claims is crucial for managing storage in Kubernetes. By creating PVs and PVCs, you can ensure that your pods have access to persistent, reliable storage, even when the pod lifecycle changes. If you need help implementing these concepts at scale, ZippyOPS offers expert consulting and managed services in Kubernetes, DevOps, DataOps, and Cloud solutions.

For more information on Kubernetes storage management and other cloud-native solutions, visit ZippyOPS Services or reach out to us at sales@zippyops.com.