Volume Types¶
A directory which is mounted inside a Pod is backed by the underlying Volume Type. A Volume Type decides the properties of the directory, like size, content, default access modes, etc. Some examples of Volume Types are:
emptyDir An empty Volume is created for the Pod as soon as it is scheduled on the worker node. The Volume's life is tightly coupled with the Pod. If the Pod is terminated, the content of emptyDir is deleted forever.
hostPath With the hostPath Volume Type, we can share a directory from the host to the Pod. If the Pod is terminated, the content of the Volume is still available on the host.
gcePersistentDisk With the gcePersistentDisk Volume Type, we can mount a Google Compute Engine (GCE) persistent disk into a Pod.
awsElasticBlockStore With the awsElasticBlockStore Volume Type, we can mount an AWS EBS Volume into a Pod.
azureDisk With azureDisk we can mount a Microsoft Azure Data Disk into a Pod.
azureFile With azureFile we can mount a Microsoft Azure File Volume into a Pod.
cephfs With cephfs, an existing CephFS volume can be mounted into a Pod. When a Pod terminates, the volume is unmounted and the contents of the volume are preserved.
nfs With nfs, we can mount an NFS share into a Pod.
iscsi With iscsi, we can mount an iSCSI share into a Pod.
secret With the secret Volume Type, we can pass sensitive information, such as passwords, to Pods.
configMap With configMap objects, we can provide configuration data, or shell commands and arguments into a Pod.
persistentVolumeClaim We can attach a PersistentVolume to a Pod using a persistentVolumeClaim.
PersistentVolumes¶
In a typical IT environment, storage is managed by the storage/system administrators. The end user will just receive instructions to use the storage but is not involved with the underlying storage management.
In the containerized world, we would like to follow similar rules, but it becomes challenging, given the many Volume Types we have seen earlier. Kubernetes resolves this problem with the PersistentVolume (PV) subsystem, which provides APIs for users and administrators to manage and consume persistent storage. To manage the Volume, it uses the PersistentVolume API resource type, and to consume it, it uses the PersistentVolumeClaim API resource type.
A Persistent Volume is a network-attached storage in the cluster, which is provisioned by the administrator.
PersistentVolumes can be dynamically provisioned based on the StorageClass resource. A StorageClass contains pre-defined provisioners and parameters to create a PersistentVolume. Using PersistentVolumeClaims, a user sends the request for dynamic PV creation, which gets wired to the StorageClass resource.
Some of the Volume Types that support managing storage using PersistentVolumes are:
1 2 3 4 5 6 7 | |
You can learn more details about Volume Types in the Kubernetes documentation.