Updated September 16, 2023
Introduction to Kubernetes Persistent Volumes
Kubernetes persistent volumes are sections of the cluster’s storage that administrators equip using repository classes. These volumes are assets in the cluster, such as nodes. They function as volume plugins, but they have a lifecycle that allows them to be detached from individual pods. Persistent volumes are commonly used for databases in Kubernetes because databases demand constant data access, and pods can be attached to persistent volumes.
Table of Content
What are Kubernetes persistent volumes?
In Kubernetes, we use the term ‘Persistent Volume’ to refer to storage resources that can be configured to manage our application’s storage needs. Persistent storage assets are distinct from individual pods and are controlled at the cluster level. A Persistent Volume represents a portion of network storage provisioned by the administrator and is available as a resource within the cluster, independent of any specific pod that may utilize it.
Kubernetes persistent volumes lifecycle
The lifecycle of a persistent volume begins with provisioning, proceeds to binding, followed by utilization, and then transitions through the stages of reclaiming, retaining, and ultimately deletion. It has some steps in its lifecycle let us discuss as follows,
Provisioning: It has static provisioning and dynamic provisioning.
Binding: It is the process that makes sure that the persistent volume can fulfill the users demand without wasting volume assets.
Using: It can fulfill the demands in which the cluster can scale only a bound volume for a pod.
Reclaiming: The cluster can avail the reclaim policy which can grow what to do with volume after its claim is released.
Kubernetes types of volumes: The Kubernetes volume is like a directory that can be accessible to the container in a pod and it has various types as given below,
- emptyDir:
When a pod gets allocated to a node, it generates an emptyDir volume. If the pod continues to run on the node for an extended period, the volume starts out empty, and the container reads and writes files to it. However, when the pod is removed, the data is also deleted from emptyDir.
- hostPath: This volume can able to scale a file or directory from the filesystem of the node.
- gcePersistentDisk: This type of volume can scale the persistent disk of Google Compute Engine into our pod and the whole data from this volume can be carried when a pod has been deleted from the node.
- awsElasticBlockStore: This volume has been organizes the amazon Wb Services Elastic Block store into our pod same as GCE persistent disk, the complete data in this volume remains undamaged when the pod has been deleted from node.
- nfs: NFS stands for Network File System, which can be mounted into our pod. The data from it is retained even when the pod is removed from the node, as only the volume is unmounted.
- iscsi: The ISCSI volume allows to existing volume SCSI over IP volume to be set into our pod.
- flocker: This volume has been used to control the data volumes which is open-source in which it allows a dataset of it to organize in our pod, if the dataset does not survive in the flocker then we need to generate it by using the API of flocker.
- glusterfs: The open-source network filesystem enables us to arrange GlusterFS into our pod.
- rbd: Rados Block Device (RBD) stands for a technology that permits us to launch it into our pod and maintain the data even after deleting the pod from the node.
- cephfs: It permits us to launch the existing volume into our pod, and we can carry the data to put on after we delete the pod from the node.
- gitRepo: It launches an empty directory and creates a duplicate git repository into it to be used by our pod.
- secret: This type of volume has been used to pass the delicate data like passwords to the pod.
- azureDiskVolume: It is used to scale a Microsoft Azure Data Disk into a pod.
Types of Kubernetes persistent volumes
The Kubernetes persistent volume types function as plugins, with some examples provided below:
- AWS elastic block store
- Azure Disk
- Azure file
- CephFS volume
- Container storage interface
- Fibre channel storage
- Flex volume
- GCE persistent disk
- Glusterfs volume
- Hostpath volume
- iSCSI
- Local storage
- Network filesystem storage
- Portworx volume
- Rados block device
- Vsphere VMDK volume
- Cinder
- Flocker storage
- Quobyte volume
- StorageOS volume
Uses protection
In the production environment like database services it needs to access the highest available data storage, Kubernetes gives a lot of flexibility when it comes to persistent data storage in which every compound can use the particular mechanism for data storage.
Kubernetes Persistent Volume Access Modes
Kubernetes Persistent Volume (PV) access modes are a concept in Kubernetes, which is an open-source container orchestration platform
- ReadWriteOnce (RWO):
- An individual node (Pod) can mount this mode, enabling it to be read-write. In other words, only one node can mount the PV at a time.
- Typically used for scenarios where a single Pod needs exclusive read-write access to the storage, such as a database.
- ReadOnlyMany (ROX):
- In this mode, multiple Pods can mount the PV as read-only simultaneously.
- Useful for scenarios where multiple Pods need to read data from the same volume but should not write to it. For example, when serving static assets.
- ReadWriteMany (RWX):
- Multiple nodes (Pods) can simultaneously mount the PV as read-write using RWX.
- Typically, you use this mode when multiple Pods need both read and write access to the same storage volume, such as for shared storage.
Kubernetes persistent – Retained, Recycled, and Deleted
- Retained: The ‘retain’ is a reclaim policy that allows for manual reclamation of the assets, when the persistent volume chain has been deleted then the PV quite exists.
- Recycled: It is a reclaim policy that executes a basic scrub on the volume and makes it accessible again for a new claim if the administrator can construct a custom recycler pod template by using the controller manager command-line argument.
- Deleted: This is a reclamation policy that the plugins have supported, which can delete objects from Kubernetes.
Conclusion
In this article, we have discussed Kubernetes persistent volumes, with administrators provisioning segments of network storage. We’ve covered various types of volumes and explored the lifecycle of Kubernetes persistent volumes. This article provides valuable insights into the concept of persistent volumes in Kubernetes, helping readers understand this crucial aspect of container orchestration.
Recommended Articles
This is a guide to Kubernetes Persistent Volumes. Here we discuss the administrator equipping a segment of network storage known as the Kubernetes persistent volume. You may also have a look at the following articles to learn more –
