CKA Certification Course - Certified Kubernetes Administrator
Storage
Volumes
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
Note
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 Option | Use Case | Example Configuration |
---|---|---|
hostPath | Single-node clusters | Uses local directory |
AWS EBS | Multi-node clusters on AWS | awsElasticBlockStore |
Azure Disk | Multi-node clusters on Azure | azureDisk |
Google Persistent Disk | Multi-node clusters on Google Cloud | gcePersistentDisk |
NFS | Shared storage across nodes | NFS 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
Watch video content