Konubinix' opinionated web of thoughts

Persistent Volume

Fleeting

The PersistentVolume subsystem provides an API for users and administrators that abstracts details of how storage is provided from how it is consumed.

A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using Storage Classes.

PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV.

There are two ways PVs may be provisioned: statically or dynamically.

StorageClasses: the PVC must request a storage class and the administrator must have created and configured that class for dynamic provisioning to occur.

So, dynamically allocated volumes are created using storage classes as “templates”.

The cluster inspects the claim to find the bound volume and mounts that volume for a Pod.

Once a user has a claim and that claim is bound, the bound PV belongs to the user for as long as they need it.

Delete the PersistentVolume. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.

Currently, volumes can either be Retained, Recycled, or Deleted.

For volume plugins that support the Delete reclaim policy, deletion removes both the PersistentVolume object from Kubernetes, as well as the associated storage asset in the external infrastructure, such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume

Specify the relevant PersistentVolumeClaim in the claimRef field of the PV so that other PVCs can not bind to it.

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: foo-pvc namespace: foo spec: storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set volumeName: foo-pv

Notes linking here