A Complete Guide to Persistent Volume Claim (PVC) in Kubernetes

⇩ Download!

Priyansh Khodiyar

Author

Share with friends

How to Use Persistent Volume Claim (PVC) in Kubernetes?

Kubernetes has emerged as the foundation of modern deployment and management. Among an array of powerful features of Kubernetes, the concept of Persistent Volume Claims (PVCs) stands out as a crucial enabler of data persistence and storage management within the Kubernetes ecosystem.

This blog is designed to provide you with the insights and knowledge needed to leverage the potential of Persistent Volume Claims effectively.

Before knowing about Persistent Volume Claims in Kubernetes, let's dig a little deeper into what is persistent Volume.

What is Persistent Volume (PV)?

A Persistent Volume (PV) is a cluster-level resource that represents a piece of storage in the cluster, such as a physical disk, network storage, or cloud storage.

It abstracts the details of the underlying storage system and provides a way to manage and allocate storage resources. PVs are created and managed by cluster administrators.

Characteristics of Persistent Volume

1. Durable Storage: PVs are meant to provide durable storage that persists beyond the lifetime of a pod. This ensures that data is retained even if pods are rescheduled or deleted.

2. Storage Classes: PVs can be associated with different storage classes, each defining a set of attributes such as storage type, performance, and provisioning mechanism.

What is a Persistent Volume Claim in Kubernetes?

A Persistent Volume Claim (PVC) in Kubernetes is a declarative request for storage resources by a pod. In the dynamic world of containerized applications, PVCs play a vital role in providing persistent storage solutions.

They act as an abstraction layer between the application and the underlying storage infrastructure, ensuring that data remains accessible and intact even when pods are created, deleted, or rescheduled.

PVCs enable pods to request a specific type and amount of storage, such as local disk, network-attached storage (NAS), or cloud-based storage.

This separation of storage requirements from the application provides more flexibility, enabling pods to be relocated between nodes or clusters without affecting the availability of related data.

Persistent Volume Claim Example

Let's say you're running a microservices-based application on a Kubernetes cluster, and one of your services requires a database with persistent storage.

Instead of hardcoding storage details directly into your application, you use PVC to request the storage you need.

This is how you can define a Persistent Storage Volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

Before diving any deeper, let's understand the difference between PVs and PVCs.

Persistent Volume (PV) vs. Persistent Volume Claim (PVC)

Let's look at an example to understand the differences between PVs and PVCs. Say you have a Kubernetes cluster and an application requiring storage

Creating Persistent Volumes

The cluster administrator creates two PVs:

• PV1: 20GB on an SSD, access mode: ReadWriteOnce, reclaim policy: Retain.
• PV2: 50GB on network-attached storage, access mode: ReadOnlyMany, reclaim policy: Delete.

Creating Persistent Volume Claims

The application developer creates two PVCs:

• PVC1: Requests 15GB storage with access mode ReadWriteOnce and requires fast storage.
• PVC2: Requests 40GB storage with access mode ReadOnlyMany and requires shared storage.

Binding PVCs to PVs

1. PVC1 will bind to PV1 because it matches in terms of capacity, access mode, and storage class.
2. PVC2 will not find a matching PV with ReadWriteMany access mode and shared storage requirements.

In summary, while Persistent Volumes are the actual storage resources, Persistent Volume Claims are requests for those resources made by applications.

The separation allows developers to focus on the storage needs of their applications without having to manage the underlying infrastructure details.

For a better understanding, let's create a Persistent Volume Claim.

How to Create a Persistent Volume Claim?

Creating a Persistent Volume Claim (PVC) in Kubernetes involves defining a PVC resource using YAML configuration and applying it to your cluster.

Here's a step-by-step guide along with an example:

Step 1: Define the Persistent Volume Claim (PVC) YAML

Create a YAML file - pvc.yaml and define your PVC configuration.*

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard

For this particular example, let's understand the properties deeply.

• accessModes: It specifies how the storage can be accessed. You can use values like "ReadWriteOnce", "ReadOnlyMany", or "ReadWriteMany" depending on your needs.
• Resources.requests.storage: This defines the requested storage capacity.
• storageClassName: This refers to the storage class that defines the type of storage to be provisioned. If not specified, the default storage class will be used.

Step 2: Apply the Persistent Volume Claim (PVC) to the Cluster

Use the kubectl command to apply the PVC configuration to your Kubernetes cluster.

For this, you can use the command:

kubectl apply -f pvc.yaml

This command will create the PVC named "example-pvc" based on the configuration defined in the pvc.yaml file.

Step 3: Verify the Persistent Volume Claim (PVC)

You can use the following command to view the created PVC and its status, with the command:

kubectl get pvc

The PVC's status "Bound" indicates that it has successfully acquired a Persistent Volume that meets its specifications.

Step 4: Using the PVC in a Pod

To use the PVC in a Pod, you can create or modify a Pod YAML to reference the PVC.

This is how you can achieve this:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: nginx
      volumeMounts:
        - name: data-volume
          mountPath: /data
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: example-pvc

In this example, the Pod named "example-pod" uses the PVC "example-pvc" that you created earlier. It mounts the PVC's storage at the path /data within the container.

Step 5: Deploy the Pod, with the command:

kubectl apply -f pod.yaml

This will create the Pod that utilizes the storage provided by the PVC.

That's it! You've successfully created a Persistent Volume Claim and used it in a Pod within your Kubernetes cluster.

How do PVs & PVCs Work?

Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) work together in Kubernetes to provide a flexible and dynamic way of managing storage resources for applications.

Here's how they work.

How do Persistent Volumes (PVs) Work?

1. Provisioning: Administrators provision PVs by connecting them to the available storage resources, and setting attributes like capacity, access modes, & storage classes.

2. Binding: When a PV is created, it's available for use, but it needs to be bound to a PVC before a pod can use it. A PV can be bound to only one PVC at a time.

3. Reclaim Policy: PVs have a reclaim policy that defines what happens to the underlying storage when the PV is released.

The policies include "Retain" (retain the data even after the PV is unbound), "Delete" (delete the data), and "Recycle" (overwrite the data and release the PV).

How do Persistent Volumes Claims (PVCs) Work?

• 1. Requesting Storage: Developers or administrators create PVCs to request storage for their applications.

  The PVC specifies the storage requirements, access modes, and optional storage class.

• 2. Dynamic Provisioning: If a suitable PV is not already available to match the PVC's requirements, dynamic provisioning can be enabled.

  This means that Kubernetes will automatically provision a new PV that matches the PVC's specifications.

• 3. Binding: Once a suitable PV is found, the PVC is bound to it. The bound PVC becomes a reference for the pod to use the requested storage.

Let's see some of the operations that you can perform with PVCs.

PVC Operations

1. Reclaiming

Reclaiming refers to the process of determining what happens to the underlying storage when a Persistent Volume (PV) is released (unbound). This behavior is defined by the reclaim policy set for the PV.

Example: Let's say you have a PV with a reclaim policy set to "Retain." When the associated PVC is deleted or released, the PV will not be automatically deleted or modified. The data will be retained, and administrators can manually decide what to do with the PV.

2. Updating a PVC

You can update a PVC to modify its attributes, such as storage size, access mode, or even the storage class it's associated with.

Example: Suppose you have a PVC named "data-pvc" requesting 10GB of storage with the "standard" storage class. You can update it to request 20GB of storage like this:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi   # Updated storage size
  storageClassName: standard

3. Deleting a PVC

Deleting a PVC removes the claim for a particular PV, making the PV available for use by other PVCs.

Example: To delete a PVC named "app-storage-pvc", use the following command:

kubectl delete pvc app-storage-pvc

4. Recycling a PVC (Deprecated)

Recycling was a reclaim policy that aimed to delete the contents of the PV once the associated PVC was deleted. However, this approach is now considered deprecated, and other mechanisms like dynamic provisioning are recommended.

5. Expanding a PVC

Expanding a PVC refers to increasing its requested storage size.

Example: Assume you have a PVC named "database-pvc" requesting 20GB of storage. You can expand it to request 30GB of storage like this:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: database-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi   # Expanded storage size
  storageClassName: standard

6. Dynamic Provisioning

Dynamic provisioning is the process of automatically creating PVs based on PVC requirements, eliminating the need for pre-provisioned PVs.

Example: If you have a PVC requesting 15GB of storage with the "fast" storage class and no matching PV is available, Kubernetes can dynamically provision a new PV with these specifications.

Always remember that the behavior of reclaiming, updating, and other operations depends on the Kubernetes distribution, storage provider, and version you're using.

Encountering errors with Persistent Volume Claims (PVCs) is not uncommon in Kubernetes deployments. Here are some common PVC-related errors and suggestions on how to fix them.

How to Mount a PV to a pod?

To mount a PersistentVolume (PV) to a Pod in Kubernetes, you need to follow these steps:

Create a PersistentVolumeClaim (PVC)

Before you can mount a PV to a Pod, you need to create a PersistentVolumeClaim (PVC) that requests storage resources from the cluster. The PVC defines the storage requirements and access mode needed by your application.

Example YAML

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

Create a Pod with the PVC

When creating a Pod, you specify the PVC as a volume in the Pod's specification. This volume will later be mounted into the container(s) within the Pod.

Example Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: my-pvc
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - name: data-volume
          mountPath: /data

Mounting the Volume Inside the Container

Within the container, you can now access the mounted volume. In this example, the volume is mounted at "/data" within the container.

Apply the YAML Files

Apply the PVC and Pod YAML files using the kubectl apply -f command as follows:

kubectl apply -f pvc.yaml
kubectl apply -f pod.yaml

Kubernetes will then manage the binding of the PV to the PVC and ensure that the Pod has access to the requested storage.

Common PVC Errors & How to Fix Them

Let's look at common Persistent Volume Claim (PVC) errors and how to fix them.

1. Insufficient Storage Capacity

Error: The PVC cannot be bound because there is not enough available storage in any of the PVs.

Solution: Check the capacity of your PVs and adjust the requested storage size in the PVC accordingly.

2. Storage Class Not Found

Error: The PVC specifies a storage class that doesn't exist.

Solution: Ensure that the specified storage class in the PVC exists. You can use kubectl to get storageclass to list available storage classes.

3. No Available PVs to Bind

Error: There are no available PVs that match the specifications of the PVC.

Solution: Check if your PVs match the access modes, storage size, and storage class defined in the PVC. You might need to create new PVs or adjust the PVC's specifications.

4. Pending State

Error: The PVC is stuck in the "Pending" state.

Solution: Check if there are available PVs that match the PVC's requirements. If not, ensure that dynamic provisioning is properly set up or create new PVs that match the PVC's specs.

5. Access Mode Mismatch

Error: The PVC's access mode does not match the available PVs' access modes.

Solution: Review the access modes specified in the PVC and ensure they match the available PVs' access modes.

When troubleshooting PVC-related errors, it's important to consult Kubernetes' event logs, describe commands (kubectl describe), and pod logs for more detailed information about the issue.

Always refer to the Kubernetes documentation for specific guidance related to your Kubernetes setup and storage provider.

Frequently Asked Questions (FAQs)

1. What is the life cycle of persistent volume claims?

Persistent Volume Claims (PVCs) in Kubernetes have a distinct lifecycle. First, they're created, specifying storage needs and access modes. Upon creation, Kubernetes seeks a matching Persistent Volume (PV) and binds them.

If a suitable PV isn't available, the PVC waits. Once bound, a PVC is used in a Pod's volume and mounted within containers. Deleting the PVC unbinds it, but the associated PV remains intact.

PVCs offer dynamic provisioning, allowing on-demand PV creation, and can be reused or deleted, making storage management efficient and adaptable.

2. Can one PV have multiple PVCs?

Yes, a single Persistent Volume (PV) in Kubernetes can be shared by multiple Persistent Volume Claims (PVCs).

This is especially useful for scenarios where multiple Pods or applications need to access the same data simultaneously. The PV's capacity and access mode must align with the combined requirements of all associated PVCs.

However, it's important to note that the sum of the PVCs' requested storage should not exceed the capacity of the PV, and access mode compatibility should be considered to avoid conflicts in read-write access.

With this, we have reached the end of the blog, and the following section gives a summary of it.

Summary: PVCs in Kubernetes

In the Kubernetes landscape, understanding Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) is very important. PVs offer dynamic storage provisioning, while PVCs act as requests for storage by Pods.

This synergy enables efficient resource management. From creating PVCs and their lifecycle operations like updating, expanding, and deleting, to optimizing with best practices and troubleshooting errors, mastering PVCs ensures smoother application storage.

Remember, while PVs provide the underlying storage, PVCs define the needed characteristics. So, whether it's grasping the fundamentals, crafting efficient PVCs, or resolving challenges, PVs and PVCs empower a great storage strategy in Kubernetes deployments.

Share with friends

Written by Priyansh Khodiyar

TwitterLinkedIn

Priyansh is the founder of UnYAML and a software engineer with a passion for writing. He has good experience with writing and working around DevOps tools and technologies, APMs, Kubernetes APIs, etc and loves to share his knowledge with others.

Further Reading