Kubernetes PVC

Understanding Persistent Volume (PV) and PVC

A persistent volume is a cluster-wide pool of storage volumes that an administrator has defined to be utilised by users building applications on the cluster. Users may now utilise Persistent Volume Claims to choose storage from this pool.

To construct a Persistent Volume (PV) with YAML, first create an empty file, then assign the appropriate access rights and describe the necessary key-value pairs.

An example of a Persistent Volume (PV) definition file is shown below.

To create the Persistent Volume based on the above YAML file, use the following command:

This command displays a list of Persistent Volumes.

Use this command to obtain additional details about the Persistent Volume:

Persistent Volume Claim (PVC)

Persistent Volume Claim is a Kubernetes object that aids in the pairing of a POD with an appropriate Persistent Volume.

To understand how the entire cycle works, let us summarize it in a few basic points:

• The administrator builds some Persistent Volumes in the organization's Storage provider.
• The user creates Persistent Volume Claims and describes the resources that their application will require in them.
• After that, the user spins up PODs that will execute their desired applications.
• The POD definition file will include the PVC name that the user created in Step 2.
• After being connected with the POD, the PVC simply links that POD to the PV that it thinks acceptable based on the specifications stated by the user in that PVC.

Types of Persistent Volumes

Persistent Volumes (PVs) are a technique to manage and abstract storage resources for containerized applications in Kubernetes. They act as a barrier between how storage is supplied and how pods utilize it.

HostPath

This sort of Persistent Volume makes use of a directory on the host machine's filesystem. It is suitable for testing and development but not for production usage since it lacks data replication and dynamic provisioning.

NFS (Network File System)

NFS is a network-based file system that allows files to be shared between computers. It may be used with Kubernetes for distributed storage, where a single NFS server supplies storage to numerous pods.

AWS EBS (Elastic Block Store)

If you're running Kubernetes on Amazon Web Services (AWS), you may use AWS EBS volumes as Persistent Volumes. EBS offers block-level storage that may be connected to EC2 instances and, as a result, Kubernetes pods.

Azure Disk

Similar to AWS EBS, Azure Disk is a Microsoft Azure block storage solution that can be utilized as Persistent Volumes in Azure-hosted Kubernetes clusters.

Creating and Managing PVCs (refer)

Defining and requesting storage resources for your application pods is part of creating and maintaining Persistent Volume Claims (PVCs) in Kubernetes. PVCs serve as an abstraction layer between the application and the underlying storage, enabling flexibility and concern separation.

Create a Persistent Volume (PV):

Before you can create a PVC, you must first have accessible Persistent Volumes in your cluster. PVs represent the real storage resources, and PVCs will request them. PVs can be built manually or dynamically using StorageClasses. Here's an example of a simple PV definition:

Create a StorageClass (Optional):

StorageClasses describe how PVs are dynamically provided. If you're utilising dynamic provisioning, define a StorageClass that provides the settings for generating PVs. If you're utilising statically provided PVs, you may skip this step. Example of a StorageClass:

Create a Persistent Volume Claim (PVC):

Pods request storage by using PVCs. In the PVC specification, provide the storage resources and access modes that will be used. Here's an example:

Bind PVC to a Pod:

In your pod's specification, refer to the PVC you prepared in the volumes section and mount it to a specified path in the container:

Apply the Configurations:

Using the kubectl apply command, apply the PV, StorageClass (if required), PVC, and Pod configurations:

Monitor and Manage

Monitor the status of your PVCs, PVs, and pods with kubectl get and other relevant commands:

Volume Modes and Access Modes

When dealing with Persistent Volumes (PVs) and Persistent Volume Claims (PVCs) in Kubernetes, you may specify how storage is utilised and accessed by pods by configuring both volume modes and access modes.

Volume Modes:

1. Filesystem (default):

   The volume is formatted with a filesystem (e.g., ext4, ext3, xfs) and may be mounted and used as a directory within the pod in this mode. It is appropriate for cases requiring a permanent file storage solution.

2. Block :

   The volume is accessible directly to the pod as a block device in block mode. The pod is in charge of administering the volume's filesystem. This mode is appropriate for applications that require direct block-level storage access.

Access Modes:

For PVs, Kubernetes provides three access modes: ReadWriteOnce, ReadOnlyMany, and ReadWriteMany.

• ReadWriteOnce (RWO) - the volume can be mounted as read/write by a single node.
• ReadOnlyMany (ROX) - the volume can be mounted as read-only by many nodes.
• ReadWriteMany (RWX) - the volume can be mounted as read/write by many nodes.

Dynamic Provisioning with Storage Classes

PVs can be provided statically or dynamically. In static PV provisioning, the storage object is built and configured on the host before being made available to the cluster. In this scenario, PODs are tied to a PV that points to a specific piece of this storage item.

If the PV is dynamically provided, a storage class object is used to describe multiple storage implementation features that point to a physical storage system. The storage class object requests a part of the storage object and then creates a volume based on the parameters in its configuration file. Storage classes enable the automated and dynamic allocation of PVs to Kubernetes objects.

A storage class object's configuration file would look like this:

The PV and PVC Lifecycle

PVCs are demand for PV resources. The following is the pattern of interaction between the two objects:.

• Provisioning:

  This is where the physical storage system is accessible to cluster users. Provisioning might be static or dynamic.

• Binding:

  The process of matching a PVC with a compatible PV and then joining them.

• Using:

  The method through which PODs consume a volume.

• Reclaiming:

  When a user has finished utilizing a volume, the binding objects are removed, allowing the storage resource to be reclaimed.Some the supported reclamation policies are:

  • Retain
  • Delete
  • Recycle

A pre-binding technique can be used to reserve certain PVs. This implies that the PVC will be tied to a PV at all times, regardless of whether its PODs are executing an application or not.

Persistent Volumes Features

Persistent Volumes in Kubernetes provide significant features. The most significant topics can be found here :

1. Capacity :

   The capacity feature allows you to specify the maximum storage capacity of the PV. Storage is given in bytes to guarantee consistency across all storage services and devices.

2. Volume Mode:

   Kubernetes builds a file system on the PV by default, however, you may utilize a raw block device directly without an extra layer if you like.

3. Access Modes:

   The following access modes are available on a PV:

   • ReadWriteOnce—enables read and write and can be mounted by only one node.
   • ReadOnlyMany—enables read-only and can be mounted by multiple nodes at the same time.
   • ReadWriteMany—enables both read and write and can be mounted by several nodes at the same time 
   • ReadWriteOncePod (alpha)—volume can be mounted as read-write by a single pod.

4. Reclaim Policy

   When the node no longer requires persistent storage, the reclaim policy determines what occurs. It can be set to Retain, which means that the PV is kept alive unless expressly erased. Recycle means that the data has been cleaned but can be recovered later, and Delete means that it has been permanently removed.

5. Phase:

   A PV passes through the following lifetime phases, which other entities in the cluster may see:

   • Available for use, binding has not occured yet
   • Bound: The PV was found to be a match for a PersistentVolumeClaim, and binding has happened.
   • Released : The user removed their PVC, but the cluster has not yet regained the PV.
   • Failed : The PV could not be automatically recovered by the cluster.

Using PVCs in Pods

Let's have a look at how we may attach any Persistent Volume Claim (PVC) in the POD definition file.

• Pods access storage in this situation by utilizing the claim as a volume. The Persistent Volume Claim must exist in the same namespace as the Pod that is utilizing it.
• The cluster locates the claim in the Pod's namespace and employs it to obtain the Persistent Volume that supports the claim. The volume is then connected to the host and inserted into the Pod.
• Persistent Volume is a cluster-scoped object, whereas Persistent Volume Claim is a namespace-scoped object.

Expanding and Resizing PVCs

Persistent Volume Claims (PVCs) in Kubernetes may be expanded and resized to improve storage space. This is useful when you need extra storage capacity for your application but don't want to create a new PVC. PVCs can be expanded and resized in the following ways:

Check StorageClass Support:

Check that the StorageClass you're using supports dynamic provisioning and resizing before proceeding. Some storage options may not allow you to resize PVCs.

Update PVC Definition:

To enlarge a PVC, you must change its resource demands.Change the PVC specification requests.storage field to the desired new size. For example:

Changes to Apply: Using kubectl apply, apply the new PVC definition:

Wait for Resize: Resizing may take some time depending on your storage provider and settings. The resize action will be initiated by Kubernetes, and the underlying storage system will do the actual resizing.Check the status of the PVC using kubectl get pvc:

Verify: When the resizing is finished, the PVC's status will be changed to "Bound." You may also inspect the filesystem size within the pod to validate that the resizing was successful.

Best Practices for Working with PVCs

The life cycle of a Persistent Volume (PV) is independent of any single container in the cluster. Persistent Volume Claims (PVC) are requests for certain types of storage made by container users or applications.

Kubernetes documentation suggests the following for building a PV:

• PVCs should always be included in the container setup.
• PVs should never be used in container setup since they firmly connect a container to a specified volume.
• Always have a default StorageClass; otherwise, PVCs without a particular class will fail.
• Give StorageClasses descriptive names.

Limitations and Caveats

Persistent Volume Claims (PVCs) in Kubernetes provide a means for applications to manage and abstract storage resources, however there are certain limits and considerations to be aware of when dealing with PVCs:

1. Storage Provider Compatibility:

   PVC dynamic provisioning and resizing is not supported by all storage options. Check that your chosen storage provider and StorageClass provide the functionality you want.

2. Access Mode Limitations:

   The restrictions of the various access modes (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) are determined by the underlying storage system. ReadWriteMany, for example, may not be supported by all storage backends.

3. Storage Classes and Volume Modes:

   Some StorageClasses or storage providers may not provide the ability to define volume modes (Filesystem or Block).

4. Limited Resizing Support:

   While resizing PVCs is conceivable, the effectiveness of the resizing may be dependent on the filesystem used in the Persistent Volume and the capabilities of the storage provider.

5. Data Consistency and Loss:

   If not handled appropriately, resizing PVCs, especially shrinking, might result in data loss. Check that your application can manage the resize without losing data.

6. No Performance Guarantees:

   PVCs do not offer performance guarantees right out of the box. If you want precise performance requirements, your storage backend may need to be configured properly.