Kubernetes Volume
There are currently two types of storage abstracts available with Kubernetes: Volumes and Persistent Volumes. A Kubernetes volume exists only while the containing pod exists. Once the pod is deleted, the associated volume is also deleted. So, the Kubernetes volumes are useful for storing temporary data that does not need to exist outside of the pod’s lifecycle. Kubernetes persistent volumes remain available outside of the pod lifecycle — this means that the volume will remain even after the pod is deleted. It is available to claim by another pod if required, and the data is retained.
Kubernetes persistent volumes are used in situations where the data needs to be retained regardless of the pod lifecycle.
PersistentVolume:
Kubernetes persistent volumes are administrator provisioned volumes. These are created with a particular filesystem, size, and identifying characteristics such as volume IDs and names.
A Kubernetes persistent volume has the following attributes
- It is provisioned either dynamically or by an administrator
- Created with a particular filesystem
- Has a particular size
- Has identifying characteristics such as volume IDs and a name
PersistentVolumeClaim:
In order for pods to start using these volumes, they need to be claimed (via a persistent volume claim) and the claim referenced in the spec for a pod. A Persistent Volume Claim describes the amount and characteristics of the storage required by the pod, finds any matching persistent volumes and claims these.
STATUS:
STORAGE CLASSES:
Above we have discussed how pv, pvc are created to claim storage. Then finally use the pvc in pod to claim volume.
The problem here is before we create PV , the google cloud disk needs to be created. So, every time application requires storage, we need to first manually provision the disk in google cloud and manually create PV definition file. This is call static provisioning.
$gcloud beta compute disks create — size 5GB — regios us-west pv-disks
It would have been nice if the volume get provision automatically when the application requires it. This is when storage class comes into picture. With storageclass we can define provisioner such as google Storage that can automatically provision storage on googlecloud and attach to Pod when claim is made- This is call Dynamic provisioning of volumes. We can do same by creating StorageClass object.
Now that we have Storage Class, PV is not required to be created anymore. Because PV and associated storage is created automatically when storage class is created.
For PVC to use the storage class we have defined , it needs to specify the Storage class name in pvc definition. This is how PVC knows which storage class to use.
Additional Notes:
- Persistent Volume and Persistent volume claim are 2 different objects in kubernetes.
- Kubernetes binds persistent volume to claim based on Request and properties set on volume.
- Every PersistentVolumeClaim is bound to single PV, during the binding process kubernetes try to find pv that has sufficient capacity as requested by the claim and any other request properties like — access mode , volume mode , Storage class.
- If there is more than 1 matches for a single Claim and you like to specially bind to specific volume; this can still be done using label and selector to bind to right volume. ( there may be chance that Smaller claim may bind to larger volume if all criteria matches and there are not better options). There is one-to-one relationship between PV and PVC, so no other claims can utilize the remaining capacities.
- StorageClass helps to dynamically provision storage.
- When using storageClass there is no need to create PV, because PV and any storage will be created automatically when StorageClass is created.
