What Is Kubernetes Persistent Storage?
Containers are an immutable form of storage, so when they shut down, any data created during their lifetime disappears. This is useful for certain applications, but other applications often need to preserve or share information. For example, an application that relies on a database requires access to persistent storage, allowing it to survive the shutdown of its containers.
The Kubernetes architecture enables persistent storage for containers in the form of Persistent Volumes (PVs). These are constructs that let you mount storage units, such as file system folders or cloud storage buckets, to Kubernetes nodes. They also allow information to be shared between nodes. When a pod shuts down, any regular volume it hosts is deleted. Persistent volumes are hosted in their own pods, so they can stay live for however long they need.
Users can request storage with PersistentVolumeClaims (PVCs), which are similar to pods, except that they consume PV resources instead of node resources.
Read more related articles: Huawei Focusing On Cloud Computing, with Access to US Chips | The 6 Most Reliable Cloud Storages for Doing Business | Careers in Big Data: Advice from an Expert
Kubernetes Persistent Storage Lifecycle
Kubernetes persistent volumes are resources in a cluster, with PVCs serving as requests for these resources. PVCs interact with PVs according to the following lifecycle.
Provisioning
PVs can be provisioned statically or dynamically:
- Static provisioning—a set of PVs containing details of the actual storage are created by the cluster administrator and made available through the Kubernetes API.
- Dynamic provisioning—if there is no static PV that matches a PVC, the cluster dynamically provisions a volume based on storage class (dynamic provisioning for the storage class must be enabled by the administrator).
The cluster administrator can enable storage clase-based dynamic storage provisioning enabling DefaultStorageClass on the API server.
Binding
The user creates a PersistentVolumeClaim requesting a certain amount of storage. The master server looks for PVs that match new PVCs and binds them when possible. Binding involves one-to-one mapping with a bi-directional ClaimRef between the PV and PVC.
Dynamically provisioned PVs will always be bound to the PVC they were created for, and bound PVCs are exclusive. If there is no matching PV, the PVC stays unbound indefinitely until a matching PV becomes available.
Using
Pods use PVCs as volumes—the cluster mounts the attached PV. If a volume supports multiple access modes, users can specify the desired mode by using the PVC as a volume. The PV will belong to the user with the bound claim.
Reclaiming
Reclaim policies tell the cluster how to treat PVs when a claim is released—it can retain, recycle or delete the volume. Users can delete PVC objects through the API when they no longer need the volume, freeing up the resource.
Want more tech news? Subscribe to ComputingEdge Newsletter Today!
Kubernetes Storage Best Practices
Volume Health Monitoring
Add CSI Volume Health Monitoring to Kubernetes to enable detection of unhealthy volumes. CSI Drivers identify and report abnormal conditions based on underlying storage systems. If you don’t implement volume health monitoring, Kubernetes does not know the state of volumes in your storage system once a PVC has been provisioned and used by a pod.
There are several issues that can arise in the underlying storage system when volumes are provisioned in Kubernetes, such as accidental deletion of a volume from outside Kubernetes or failure of the host disk. These issues affect performance and can be difficult to remediate. For example, it’s not easy to detect the root cause or debug a file system if volumes are corrupted or mounted from outside Kubernetes.
Kubernetes users can benefit significantly from monitoring volume health, as part of a holistic Kubernetes monitoring strategy. The CSI driver can detect and communicate errors in the underlying storage system, reporting PVC events to the user, who can then take action. If a volume has reached capacity, for example, the user can request to expand the volume.
Resource Quotas for Namespaces
Resource quotas can work at the namespace level to provide an additional layer of control over your cluster resource usage. A resource quota limits the total amount of resources (storage, memory and CPU) that the containers running in the same namespace can consume.
You can also limit the consumption of resources by PVCs based on storage class. Define the storage classes according to your backup policy and service-level qualities. Check if your resource quotas are configured using the kubectl describe namespace <namespace_name> command.
Select Optimized Storage Equipment
Kubernetes can use a variety of persistent volume types, making it extremely extensible and flexible. Kubernetes providers may use quality-of-service levels to extend the schema definitions of PVCs. This offers prioritized read/write quotas for volume in specific deployments, enhancing throughput in various circumstances.
There are various types of hardware for persistent storage (like there are different types of memory chips and CPUs), and each storage option offers different benefits. A solid state drive (SDD) typically offers better performance in terms of read/write, compared to a hard disk drive (HDD). A non-volatile memory express (NVMe) SSD is best suited for heavier workloads.
Generally speaking, better hardware means better performance, although the order of performance is typically according to a constant factor. If, for example, you choose to upgrade from an SSD to an NVMe SSD, you can expect an increase in read/write operations without having an effect on network latency.
Conclusion
In this article I discussed how Kubernetes handles persistent storage, the lifecycle of a Persistent Volume (PV), and best practices that can help you make the most of your persistent storage:
