PersistentVolume
最后更新于
PersistentVolume (PV) and PersistentVolumeClaim (PVC) offer a handy tool to manage persistent volumes: PV provides network storage resources, and PVC requests these resources. As such, setting a persistent workflow involves configuring the underlying file system or cloud data volume, creating a persistent data volume, and then creating a PVC to link your Pods with the data volume. With PV and PVC, Pods and data volumes can be decoupled, meaning that Pods don't need to know the exact file system or the persistent engine that supports them.
The lifecycle of a volume goes through five stages:
Provisioning - the creation of PVs, can be done directly (statically) or dynamically using a StorageClass.
Binding - Assigning PVs to PVCs
Using - Pods can use the volume via the PVC, and stop the deletion of a PVC that is in use via the admission control of StorageObjectInUseProtection (PVCProtection for versions 1.9 and earlier).
Releasing - Pods release the volume and delete the PVC
Reclaiming - The PV is retrieved. It can be retained for future use, or it can be directly deleted from the cloud storage. Finally, both the PV and the backend storage are deleted.
Based on these 5 stages, we have four volume statuses:
Available
Bound
Released (PVC unbound, but reclaim policy not yet executed)
Failed
Kubernetes Version | PV / PVC Version | StorageClass Version |
---|---|---|
A PersistentVolume (PV) is a piece of network storage residing within the cluster. Similar to a Node, it's a resource of the cluster. PV shares similarities with Volume but has a lifecycle that's independent of Pods. Let's take the example of an NFS-based PV:
In the existence of many volumes, creating an NFS Volume manually is not very convenient. Kubernetes also provides a StorageClass to dynamically create PVs, saving administrators time and encapsulating different types of storage for PVCs to select.
While PV is a storage resource, a PersistentVolumeClaim (PVC) is a request for a PV. PVCs are like Pods: Pods consume Node resources and PVCs consume PV resources. They can request specific storage sizes and access modes, just as Pods can request CPU and memory resources.
Starting from v1.8, Kubernetes supports expanding PV space. It allows you to expand the size of a PV without losing data or restarting containers. Please note that the current implementation only supports PVs that don't need to adjust the file system size and supports a few storage types.
Starting from v1.9, Kubernetes has added a new Raw Block Volume feature. Raw Block Volume enables raw block devices to be used as K8s volumes. Note that before you use this feature, you need to enable the BlockVolume feature for kube-apiserver, kube-controller-manager, and kubelet.
Starting from v1.11, when you enable the admission control StorageObjectInUseProtection, PVs and PVCs that are in use will not be deleted immediately after the delete command is issued. Instead, they'll go through a graceful termination process once the users delete the objects.
More detailed information can be found in the reference section below.
Kubernetes Persistent Volumes Kubernetes Storage Classes Dynamic Volume Provisioning Kubernetes CSI Documentation Volume Snapshots Documentation
v1.5-v1.6
core/v1
storage.k8s.io/v1beta1
v1.7+
core/v1
storage.k8s.io/v1