Volumes

Containers are designed to be transient: they process data and then are removed. By default, any data written inside a container is lost when that container is deleted. To preserve data beyond a container’s lifetime, mount a volume into the container so files are written to storage outside the container filesystem.

A diagram titled "Volumes" showing a shared /data storage area with file and database icons, connected by lines to a row of container/pod icons below. It illustrates multiple containers mounting the same storage volume.

How this maps to Kubernetes Kubernetes pods are also ephemeral. When a pod is deleted, any data written inside the pod is removed unless the pod wrote that data into a mounted volume. Attaching a volume to a pod lets containers persist data to that volume; the volume can outlive the pod. Note that not all Kubernetes volume types are persistent—emptyDir, for example, is ephemeral and deleted when the pod is removed. To retain data beyond a pod’s lifetime, use a backing store that persists independently of the pod: e.g., hostPath (node filesystem), network-backed storage (NFS, GlusterFS, CephFS), cloud block/file storage (AWS EBS, Azure Disk/File, GCP PD), or Kubernetes PersistentVolumes (PV) provisioned via a CSI driver. Example: ephemeral pod (no volume) This pod writes a random number to /opt/number.out. Because no volume is mounted, the file disappears once the pod is removed.

apiVersion: v1
kind: Pod
metadata:
  name: random-number-generator
spec:
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - shuf -i 1-100 -n 1 >> /opt/number.out

Note: The Alpine base image may not include the shuf utility by default. For this example you may need an image that contains shuf or install the appropriate package (e.g., coreutils or shuf) in the container.

Persisting data by mounting a volume To retain the generated number, attach a volume and mount it inside the container. The example below uses a host directory (/data) on the node as the backing storage and mounts it at /opt inside the container. Anything written to /opt is stored on the node under /data.

apiVersion: v1
kind: Pod
metadata:
  name: random-number-generator
spec:
  restartPolicy: Never
  containers:
  - name: alpine
    image: alpine
    command: ["/bin/sh", "-c"]
    args:
      - shuf -i 1-100 -n 1 >> /opt/number.out
    volumeMounts:
    - name: data-volume
      mountPath: /opt
  volumes:
  - name: data-volume
    hostPath:
      path: /data
      type: DirectoryOrCreate

When this pod runs it appends a random number to /opt/number.out. Because /opt is backed by the node path /data, the file persists on the node at /data/number.out. Deleting the pod does not delete that host file.

Using hostPath directly ties storage to a specific node’s filesystem. This is acceptable for single-node clusters or development/testing, but it is not recommended for production multi-node clusters because the data is not automatically shared or replicated across nodes.

Volume storage options Kubernetes supports many storage backends. Choose the backend based on durability, access mode (ReadWriteOnce, ReadOnlyMany, ReadWriteMany), performance, and whether the storage must be accessible across nodes. CSI drivers are the recommended plugin mechanism for most cloud and on-premises storage solutions.

Storage category	When to use	Example / note
Node-local	Fast local disk; data tied to one node	`hostPath` (not for production multi-node)
Network file systems	Share files across many pods/nodes	NFS, GlusterFS, CephFS — good for ReadWriteMany
Block storage	High performance, often single-AZ	AWS EBS, GCE Persistent Disk, Azure Disk — typically ReadWriteOnce per zone
Managed cloud file services	Shared file storage with cloud provider	Azure File, AWS EFS, Google Filestore — provide ReadWriteMany in many cases
CSI-backed volumes	Modern, extensible driver model	Any storage supported by a CSI driver (recommended)

Example: AWS EBS block storage (in-tree volume type shown for illustration)

volumes:
- name: data-volume
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

Keep in mind: block storage such as AWS EBS is usually tied to a single availability zone and cannot be mounted read-write by pods on multiple nodes simultaneously unless the underlying plugin and volume support multi-attach or shared modes. Best practices and next steps

Prefer dynamic provisioning via PersistentVolume and PersistentVolumeClaim (PV/PVC) backed by a CSI driver for production workloads.
Select storage based on access mode requirements: if multiple nodes need RW access, use shared network or file storage (ReadWriteMany).
Avoid hostPath for production multi-node clusters.
Use Kubernetes StorageClasses to define performance tiers and dynamic provisioning policies.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Watch Video