Cloud Native 28 min read

Introduction to Kubernetes Storage Volumes and Their Types

This article provides an overview of Kubernetes storage options, describing temporary and persistent volume types such as EmptyDir, HostPath, ConfigMap, Secret, PersistentVolume, PersistentVolumeClaim, StorageClass, and NFS, and includes practical YAML examples for creating and using each storage solution in a cluster.

Test Development Learning Exchange
Test Development Learning Exchange
Test Development Learning Exchange
Introduction to Kubernetes Storage Volumes and Their Types

Kubernetes (K8s) offers a variety of storage types to satisfy different application needs. The main categories include temporary storage, persistent storage, ConfigMap and Secret, and the special EmptyDir volume.

Temporary Storage – short‑lived and volatile, usually created on local storage and automatically removed when the Pod terminates.

Persistent Storage – survives Pod termination and can be provisioned by plugins such as NFS, GlusterFS, or Ceph. It is requested via a PersistentVolumeClaim (PVC) and supplied by a PersistentVolume (PV).

ConfigMap and Secret – special volume types that let you inject configuration files or encrypted data into containers, either by mounting them as volumes or exposing them as environment variables.

EmptyDir – a temporary directory created on each node for a Pod; it is recreated on a new node when the Pod moves.

Kubernetes supports many volume types that can be mounted into Pods. Common examples include:

EmptyDir – temporary, node‑local, deleted with the Pod.

HostPath – maps a host directory into a container (useful for testing, not recommended for production).

PersistentVolume (PV) and PersistentVolumeClaim (PVC) – cluster‑wide persistent storage resources.

ConfigMap and Secret – inject configuration or sensitive data.

StorageClass – defines a class of storage with specific parameters and behavior.

Example: Using EmptyDir to store log files

apiVersion
:
v1
kind
:
Pod
metadata
:
name
:
logging-pod
spec
:
containers
:
-
name: log-generator
image
:
busybox
command
:
-
sh
-
"-c"
-
"while true; do echo 'Logging message' >> /data/log.txt; sleep 1; done"
volumeMounts
:
-
mountPath: /data
name
:
log-data
volumes
:
-
name: log-data
emptyDir
:
{}

This pod creates a temporary emptyDir volume at /data where the container continuously writes log messages.

Example: Injecting a ConfigMap into a Pod

apiVersion
:
v1
kind
:
ConfigMap
metadata
:
name
:
my-configmap
data
:
app.properties
:
|
username
=
admin
password
=
secret
---
apiVersion
:
v1
kind
:
Pod
metadata
:
name
:
app-pod
spec
:
containers
:
-
name: app-container
image
:
my-app
envFrom
:
-
configMapRef:
name
:
my-configmap

The ConfigMap provides configuration data that the container consumes as environment variables.

Example: PersistentVolume and PersistentVolumeClaim

apiVersion
:
v1
kind
:
PersistentVolume
metadata
:
name
:
pv0001
spec
:
capacity
:
storage
:
5Gi
accessModes
:
-
ReadWriteOnce
nfs
:
path
:
/exports/my-nfs
server
:
my-nfs-server.example.com
---
apiVersion
:
v1
kind
:
PersistentVolumeClaim
metadata
:
name
:
pvc-claim0001
spec
:
accessModes
:
-
ReadWriteOnce
resources
:
requests
:
storage
:
5Gi

The PV is backed by an NFS server, and the PVC requests 5 GiB of that storage for use by a Pod.

Example: HostPath Volume

mkdir -p /data/hostpath
echo "Hello from host file system!" > /data/hostpath/hello.txt
apiVersion
:
apps/v1
kind
:
Deployment
metadata
:
name
:
hostpath-test
spec
:
replicas
:
1
selector
:
matchLabels
:
app
:
hostpath-test
template
:
metadata
:
labels
:
app
:
hostpath-test
spec
:
containers
:
-
name: test-container
image
:
busybox:latest
command
:
["sh", "-c", "cat /mnt/data/hostpath/hello.txt && tail -f /dev/null"]
volumeMounts
:
-
mountPath: /mnt/data/hostpath
name
:
hostpath-vol
volumes
:
-
name: hostpath-vol
hostPath
:
path
:
/data/hostpath

This deployment mounts the host directory into the container, allowing the container to read the file created on the host.

Example: NFS Volume

sudo
apt-get install nfs-kernel-server
sudo
mkdir -p /nfs/shared
sudo
chmod -R 777 /nfs/shared/
sudo
nano /etc/exports
/nfs/shared *(rw,sync,no_subtree_check)
sudo
service nfs-kernel-server restart
apiVersion
:
v1
kind
:
PersistentVolume
metadata
:
name
:
nfs-volume
spec
:
capacity
:
storage
:
1Gi
accessModes
:
-
ReadWriteMany
nfs
:
path
:
/nfs/shared
server
:
YOUR_NFS_SERVER_IP
apiVersion
:
v1
kind
:
PersistentVolumeClaim
metadata
:
name
:
nfs-claim
spec
:
accessModes
:
-
ReadWriteMany
resources
:
requests
:
storage
:
1Gi

After creating the PV and PVC, a Pod can mount the NFS share to share data across nodes.

StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gp2
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2

A PVC that references this StorageClass requests 5 GiB of storage:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: ebs-claim
spec:
accessModes:
- ReadWriteOnce
storageClassName: gp2
resources:
requests:
storage: 5Gi

The PVC can then be mounted into a Pod to provide persistent storage backed by AWS EBS.

Other Volume Types

Kubernetes also supports GlusterFS, Ceph, iSCSI, Azure Disk, Local Volume, CSI drivers, and Ephemeral volumes. Each can be defined via a PersistentVolume and claimed with a PVC, allowing flexible storage solutions for various workloads.

Overall, understanding the different volume types, their use‑cases, and how to configure them with YAML manifests is essential for building reliable, stateful applications on Kubernetes.

KubernetesNFSConfigMapemptyDirHostPathPersistentVolumeStorageClassStorageVolumes
Test Development Learning Exchange
Written by

Test Development Learning Exchange

Test Development Learning Exchange

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.