Skip to main content
Hello, and welcome to this lesson on persistent volumes in Kubernetes. My name is Mumshad Mannambeth. In this lesson, we will start by exploring volumes in Kubernetes and comparing them to Docker volumes, then move on to a practical example and discuss different storage options.

​
Overview of Volumes in Docker

Docker containers are designed to be transient: they are created as needed, process data, and are then destroyed. As a consequence, any data stored within a container is lost when the container is removed. To overcome this limitation, Docker allows you to attach a volume to a container so that the data persists even after the container’s lifecycle ends.

​
Volumes in Kubernetes

Similarly, Kubernetes pods are ephemeral by design. When a pod processes data and is subsequently deleted, the data inside it is normally lost. To retain this data, a volume is attached to the pod. Any data generated by the pod is stored in the volume and remains available even after the pod is terminated.

​
A Simple Example of Using Volumes

Consider a scenario where you have a single-node Kubernetes cluster. A pod generates a random number (between 0 and 100) and writes it to the file /opt/number.out. Without a volume, this file would be lost when the pod is deleted. By attaching a volume that uses a directory on the host for storage, the generated number is preserved. In this example, the volume is configured to use the host’s /data directory. This implies that any files created within the volume (for instance, the random number written to /opt/number.out in the container) are stored in /data on the node. The volume is then mounted to the /opt directory inside the container. Below is the YAML configuration for the pod: 
apiVersion: v1
kind: Pod
metadata:
  name: random-number-generator
spec:
  containers:
  - image: alpine
    name: alpine
    command: ["/bin/sh", "-c"]
    args: ["shuf -i 0-100 -n 1 >> /opt/number.out;"]
    volumeMounts:
    - mountPath: /opt
      name: data-volume
  volumes:
  - name: data-volume
    hostPath:
      path: /data
      type: Directory
When the pod executes the command, the random number is written to /opt/number.out inside the container. Since /opt is mounted to the host’s /data directory, the file persists on the host even after the pod is deleted.

​
Volume Storage Options

In the above example, we utilized a hostPath volume, which is suitable for a single-node cluster. However, this approach is not ideal for multi-node clusters where each node’s /data directory may differ. For such environments, Kubernetes supports several external and replicated storage solutions. Some popular storage options include:
  • NFS
  • GlusterFS
  • Flocker
  • Fibre Channel
  • CephFS
  • ScaleIO
  • Public cloud storage solutions like AWS EBS, Azure Disk or File, and Google Persistent Disk
For example, to use an AWS Elastic Block Store (EBS) volume, replace the hostPath configuration with AWS EBS-specific parameters such as the volume ID and filesystem type. This allows your Kubernetes cluster to leverage AWS EBS for robust, scalable storage.
For a quick comparison, refer to the table below:
Storage OptionUse CaseExample Configuration
hostPathSingle-node clustersUses local directory
AWS EBSMulti-node clusters on AWSawsElasticBlockStore
Azure DiskMulti-node clusters on AzureazureDisk
Google Persistent DiskMulti-node clusters on Google CloudgcePersistentDisk
NFSShared storage across nodesNFS volume configuration

​
Conclusion

This lesson provided an overview of volumes in Kubernetes by comparing them with Docker volumes and demonstrating how to use a hostPath volume for data persistence. In our next lesson, we will explore persistent volumes in Kubernetes, which offer advanced storage management and additional capabilities tailored for multi-node clusters. For further reading, check out these resources:

Watch Video