Pods are ephemeral and stateless.
Volumes bring persistence to pods.
Containers has access to volume with in a same pod.
If node stops working, the pod can be rescheduled on another node and the volume can be attached to the new node.
It support many types of Storages.

[Volumes]
✤ awsElasticBlockStore
An awsElasticBlockStore volume mounts an Amazon Web Services (AWS) EBS volume into pod.
It is erased when a pod is removed, the contents of an EBS volume are persisted and the volume is unmounted.
The EBS volume can be pre-populated with data, and that data can be shared between pods.
It must create an EBS volume by using an command (aws ec2 create-volume) OR the AWS API before can use it.
There are some restrictions when using an awsElasticBlockStore volume:-
● The nodes on which pods are running must be AWS EC2 instances.
● Those instances need to be in the same region and availability zone as the EBS volume.
● EBS only supports a single EC2 instance mounting a volume.

✤ emptyDir
It creates empty directory first created when a Pod is assigned to a node.
It stays as long as pod is running.
Once pod is removed from a node, emptyDir is deleted forever. (OR) When a Pod is removed from a node for any reason, the data in the emptyDir is deleted permanently.
It's an temporary space.   
The emptyDir volume is initially empty. 
All containers in the Pod can read and write the same files in the emptyDir volume, though that volume can be mounted at the same or different paths in each container.
An emptyDir volume recreates when containers restart or crash. The data in this volume is deleted and lost when the pod is removed from the node, crashes, or dies.

✤ hostPath
A hostPath volume mounts a file or directory from the host node's filesystem into Pod.
The data is persistence even after the pod is terminated.
● "type: Directory" 
A directory must exist in the specified path.
● "type: DirectoryOrCreate" 
If no content is found in the specified path, an empty directory is created on demand.
The permission on the created directory is set to 0755.
The directory has the same group and ownership with kubelet.
● "type: File" 
A file must exist in the given specified path.
● "type: FileOrCreate" 
If no content is found in the specified path, an empty file is created.
The permission of the created file is set to 0644.
The file has the same group and ownership with kubelet.

✤ gitRepo
A gitRepo volume is an example of a volume plugin.
This plugin mounts an empty directory and clones a git repository into this directory for Pod to use.

[Ephemeral Volumes]
Ephemeral Volumes is a temporary space.
Ephemeral Volumes in the sense that it is cleaned up when the workload is deleted or the container crashes.
There are many types of Ephemeral Volumes.
● emptyDir
The emptyDir are provided as local ephemeral storage. They are managed by kubelet on each node.
● configMap, downwardAPI, secret
It inject different kinds of Kubernetes data into a Pod.
The configMap, downwardAPI, secret are provided as local ephemeral storage. They are managed by kubelet on each node.
● CSI ephemeral volumes
It provided by special CSI drivers.
CSI ephemeral volumes must be provided by third-party CSI storage drivers.
● generic ephemeral volumes
It can be provided by all storage drivers that also support persistent volumes.
Generic ephemeral volumes can be provided by third-party CSI storage drivers, but also by any other storage driver that supports dynamic provisioning.
Some CSI drivers are written specifically for CSI ephemeral volumes and do not support dynamic provisioning: those then cannot be used for generic ephemeral volumes.

[Storage Classes (SC)]
First the StorageClass is created, then the PersistentVolumeClaim and finally the Pod.
When a PVC is created, Kubernetes creates a PersistentVolume and binds it to the PVC automatically, depending on the VolumeBindingMode used in the StorageClass configuration.
It allows dynamic provisioning of Persistent Volumes, when PVC claims it.
StorageClass is used with PVC that allow Pods to dynamically request a new storage.
For each and every Storage Classes thier will be a Persistent Volume Claim (PVC).
StorageClass use provisioners that are specific to the storage platform or cloud provider to give Kubernetes access to the physical storage.
Each storage backend has own provisioner. Storage Backend is defined in the StorageClass component via provisioner attribute.
If using a provisioner, usually don't create the PV. Just create a PVC requiring that created StorageClass.
Components of Storage Classes in YAML file.
● provisioner
It is a type of volume plug-in that handles the creation and management of storage within Kubernetes.
Some provisioners are built in and shipped with Kubernetes and some are third-party provisioners, which is helpful when internal provisioners don’t support use case.
Third-party provisioners are not shipped with Kubernetes, but are developed and maintained by third-party vendors.
● volumeBindingMode
There are two volume binding modes that can be used:
* Immediate - This mode involves the automatic volume binding of PV to PVC with a StorageClass once a PVC is created.
              In this mode, the volume and storage binding are created immediately after the PVC is created.
              So whenever a new PVC with the standard storage StorageClass is created, can see it in the bound state.
              This mode is universally supported.
* WaitForFirstConsumer - This mode will delay the binding and dynamic provisioning of PV, until a Pod that will use it is created.
                         In this mode, volume is not created until a pod that consumes the PVC is created.
                         Most plug-ins don’t support this mode, but only "Amazon Elastic Block Store", "Google Compute Engine Persistent Disk" and "Azure Disk" support it.

[Persistent Volumes (PV)]
It is an abstraction for the physical storage device that attached to the cluster.
PV is not Namespaced it is available to whole cluster. PV is accessible to all Namespaces.
It no need to create StorageClass for PV.

[Persistent Volume Claims (PVC)]
It is binding between a Pod and PV. Pod request the Volume through the PVC.
It is the request to provision persistent storage with a specific type and configuration.
Pods consume node resources and PVC consume PV resources.
PVC describe the storage capacity and characteristics a pod requires, and the cluster attempts to match the request and provision the desired persistent volume.
PVC must be in same namespace as the Pod. For each Pod, a PVC makes a storage consumption request within a namespace.

⦿ PVC to PV binding is a one-to-one mapping. The process uses a ClaimRef, which creates a bi-directional binding between PV and PVC.

⦿ Persistent Volume (PV) is an abstraction for the physical storage device that have attached to the cluster.
   Pods can use this storage space using Persistent Volume Claims (PVC).
   To create the PV-PVC pair for Pod is to use a StorageClass (SC) object, and then using the StorageClass to create PV-PVC pair dynamically.

{Reclaim Policy (reclaimPolicy,persistentVolumeReclaimPolicy)}
It is the policy that describes how a storage class can reclaim a PV when it is no longer needed.
If no 'reclaimPolicy' is specified when a StorageClass object is created, it will default to 'Delete'.
PV that are created manually and managed via a StorageClass will have whatever reclaim policy they were assigned at creation.
PV that are dynamically created by a StorageClass will have the reclaim policy specified in the reclaimPolicy field of the class, which can be either Delete or Retain.
● Delete
It will delete the data immediately.
● Retain
It will keep the data until the user deletes it.
● Recycle
It deletes the volume’s contents and makes the volume available to be claimed again.
This policy is now deprecated.

{Access Modes (accessModes)}
There are 4 types of Access Modes.
● ReadWriteOnce(RWO)
The volume can be mounted as read-write by a single node.
Only a single node can mount the volume for reading and writing.
This access mode still can allow multiple pods to access the volume when the pods are running on the same node.
● ReadOnlyMany(ROX)
The volume can be mounted read-only by many nodes.
The volume can be mounted by multiple nodes for reading.
● ReadWriteMany(RWX)
The volume can be mounted as read-write by many nodes.
Multiple nodes can mount the volume for reading and writing.
● ReadWriteOncePod(RWOP)
The volume can be mounted as read-write by a single Pod.
This access mode if want to ensure that only one pod across whole cluster can read that PVC or write to it. 
This is only supported for CSI volumes and Kubernetes version 1.22+.

{Phase}
● Available
A free resource that is not yet bound to a claim.
● Bound
The volume is bound to a claim.
● Released
The claim has been deleted, but the resource is not yet reclaimed by the cluster.
● Failed
The volume has failed its automatic reclamation.
