Kubernetes provides persistent storage to help you deploy stateful applications. Without it, data would be lost when Pods restart or fail.
Cluster administrators provision storage through Persistent Volume Claims (PVC). Developers then use a PVC in a Pod’s volumes block to access the cluster storage. The cluster’s reclaim policy decides what happens next when a PVC is unbound.
What are Persistent Volumes?
Persistent Volumes decouple storage from the lifecycle of a pod, allowing data to be preserved even if a pod is terminated or rescheduled. They are essential for maintaining services that require persistent storage, such as databases.
In the case of a PV, the Kubernetes cluster uses an API object called a Persistent Volume Claim (PVC) to request storage from a backend storage provider. A PVC consists of desired storage specifications, such as size, access mode, and StorageClass. A PVC is matched with a storage system using a provisioning policy that matches it with resources available on the host node. Once the PV is provisioned, it is bound to a pod via a PVC and mounted inside it.
A Pod can contain multiple Persistent Volume Claims, and a Deployment can deploy stateful applications with unique Persistent Volume Claims for each replica Pod in the Deployment. This allows for a safe restart of your workload and guarantees that all replicas have access to the same data. The reclaim policy of the PV specifies whether it is a persistent or temporary resource and how long its contents should be retained.
Persistent Volumes and Claims
Persistent Volumes abstract the details of how storage is provisioned and consumed. Pods gain access to PVs by creating a Persistent Volume Claim object, which requests a specific amount of storage and the desired access mode. If a PV matches the request, it is bound to the PVC and mounts into the Pod’s filesystem. The Pod can exit the Deployment anytime, and the volume will remain intact, preserving everything that the Pod wrote.
Storage abstraction is essential because it enables applications to work with data independent of the application containers, allowing for scalable, resilient deployments. Kubernetes volume mount permissions provide this capability for various use cases, such as database storage, file sharing, and IoT data management.
Kubernetes uses resource quotas to limit the memory, CPU, and storage available to Pods. Persistent Volumes allow administrators to apply these quotas flexibly and efficiently to meet their application requirements.
A Persistent Volume Claim can specify a number of requirements using matchLabels and matchExpressions. These matchExpressions can include filtering by size, access mode, and storage class. If a matchExpression is applied, only a PV with that matching specification can be bound to the PVC. Once a PV is bound to a Persistent Volume Claim, the Pod can schedule a job to use that volume. If the Pod scheduler uses a Persistent Volume Claim, the cluster will inspect that claim and determine the appropriate backing volume to mount for the job.
Persistent Volumes in Kubernetes
Persistent Volumes serve as long-term storage for your cluster, decoupling storage from pods. They are accessed by Pods using persistent volume claims (PVC). A PVC is a storage request. It specifies the storage class to use for dynamic provisioning of a PV and the storage interface for the PVC to communicate with your backend storage.
Persistence is important for several reasons. For example, writing container logs to a persistent volume ensures they will be available after the pod reboots or crashes. This is particularly useful if the data stored in your Pod is sensitive or requires recovery from failure.
When you have a PVC, it can be bonded to a PV through storage allocation. This control loop looks for a PV that meets the required storage parameters such as size, access mode, and StorageClass. If a PV satisfies the requirements, it is bound to the PVC, and the PVC mounts it in the Pod.
This decoupling of the Pod and its storage makes your Pod specification portable between different clusters or environments. It also allows you to run stateful applications without worrying about the consequences of a Pod restart or crash. As a result, you can be more confident that your Deployment will work as expected, regardless of the environment in which it runs.
Persistent Volumes and Storage Classes
A persistent volume (PV) represents a storage resource in your cluster. It is accessed by creating a Persistent Volume Claim (PVC).
The PVC is similar to a voucher your deployment applications can redeem for storage access. It provides an abstraction of how your applications gain access to the storage, and it can be reclaimed and reused after a failure without losing data.
Each PV has a state that determines its availability for use by Pods, and its reclaim policy controls this. The reclaim policy can be Retain, Recycle, or Delete. The Retain reclaim policy allows manual volume reclamation for storage volume plugins that support this. The Recycle reclaim policy recycles the volume into the pool of unbound persistent volumes once other claims no longer need it. The Delete reclaim policy causes the PV to be deleted from Kubernetes and, depending on the plugin, could also remove it from external infrastructure.
