🏷️ Configure volume types, access modes and reclaim policies#
Volume types, accessModes and Reclaim Policy
Volume types refer to the underlying storage systems that a PersistentVolume (PV) can be backed by. Kubernetes supports various volume types, including NFS, iSCSI, local storage (hostPath), and cloud provider-specific options like AWS EBS, Google Persistent Disk, and Azure Disk. The Container Storage Interface (CSI) enables integration with third-party storage providers, expanding the range of available storage solutions. Additionally, volumes can be configured as either a filesystem (the default) or a block device, specified via the volumeMode parameter.
Access modes define how a PV can be accessed by pods. The three primary access modes are:
ReadWriteOnce(RWO), which allows a single node to mount the volume in read-write mode;ReadOnlyMany(ROX), which allows multiple nodes to mount the volume in read-only mode;ReadWriteMany(RWX), which allows multiple nodes to mount the volume in read-write mode.
A newer mode, ReadWriteOncePod, allows a single pod to access the volume in read-write mode.
A volume can only use one access mode at a time, even if it supports multiple.
Reclaim policies determine what happens to the underlying storage when a PersistentVolumeClaim (PVC) is deleted.
The
Retainpolicy keeps the PV and its data after the PVC is deleted, requiring manual cleanup by an administrator.The
Deletepolicy removes both the PV object and the associated external storage asset (e.g., an AWS EBS volume).The
Recyclepolicy, which performs a basic scrub of the volume, is deprecated and no longer recommended due to potential data security issues.
The choice of reclaim policy depends on the storage provider and the desired data retention strategy.
Ephemeral volumes
Ephemeral volumes exist only for the lifetime of a Pod and are deleted when the Pod is removed. Common types include:
emptyDir: Created when a Pod is assigned to a node and is initially empty. It provides temporary storage for scratch space or data sharing between containers within the same Pod. Data is lost when the Pod is deleted or rescheduled.hostPath: Mounts a file or directory from the host node’s filesystem into a Pod. This is useful for accessing node-specific data but is not recommended for stateful applications due to node dependency; data is lost if the Pod moves to another node.ConfigMapandSecret: These are used to manage configuration data and sensitive information (like API keys), respectively. They can be mounted as volumes to inject data into containers.downwardAPI: Exposes pod metadata (e.g., name, labels, annotations) to containers within the Pod via a volume.projected: Combines multiple volume sources (e.g., ConfigMap, Secret, DownwardAPI) into a single volume for unified access.
See 🌐 kubernetes.io - volume-types .
Persistent Volumes
Persistent volumes (PVs) are independent of the Pod lifecycle and can persist data beyond the Pod’s existence. They are managed through PersistentVolumeClaims (PVCs), which are requests for storage resources.
PersistentVolume (PV): A piece of storage in the cluster provisioned by an administrator or dynamically via StorageClasses. It can be backed by cloud provider storage (e.g., AWS EBS, Azure Disks, GCE Persistent Disks), NFS, iSCSI, or local storage devices.
PersistentVolumeClaim (PVC): A user request for storage that binds to a suitable PV based on size, access mode, and other requirements.
CSI (Container Storage Interface): A standard interface that allows Kubernetes to integrate with external storage providers (e.g., NetApp, Portworx, Dell EMC) without requiring custom code for each provider.
NFS: Allows mounting a Network File System into a Pod, enabling shared storage across multiple Pods and nodes.
Local: Refers to storage mounted directly on a node’s local device (e.g., partition, disk), useful for high-performance workloads but not suitable for multi-node clusters due to node dependency.