Storage with Kubernetes
Storage with Kubernetes
Every project and application requuires storage, and Kubernetes Volumes provides a number of options for supportion application with various needs.
Join the DZone community and get the full member experience.Join For Free
Storage is a common need for applications. They need it to store log files, configuration files, artifacts, media, and more. When applications run in a web server, they use the disk space on the server to store these files. However, when they run in a container, allocating a disk space is not so straightforward. There are several considerations when creating a strategy for container volumes:
- On-disk files in a container may be ephemeral.
- The container gets re-spawned, losing any files it has.
- Files are needed to be shared across containers.
- Files may be needed beyond the lifespan of pods.
One of the advantages of using Kubernetes for managing containers is that it provides several options to meet different storage needs.
Kubernetes Volume is a directory on a disk backed by some media. This Volume is available to all containers running inside a Pod. The Pod specification mentions what kind of volume is to be provisioned and where to mount it. The kind of Volume is specified by choosing one between many Volume Types that Kubernetes provides. Some of these are:
- AWS EBS
- Azure Disk
- Ceph file system
This kind of Volume is created when a Pod is scheduled on a node. This volume is for the lifetime of the pod only. It gets deleted as soon as pod is terminated. All containers within the Pod share this volume. The use case for such a volume can be to use as a temporary space for applications internal work or use as a cache for improving the performance of applications. See the below pod specification:
AWS EBS, Azure Disk, and GCE Persistent Disk
AWS/AKS/GKE and other cloud providers provide storage to be used by their managed Kubernetes services. Consider the following example where the Pod specification makes use of an Azure Disk:
In the above specification,
diskName: Name of the VHD blob object
diskURI: URI of the VHD blob
The pod specifications we saw so far all mention the type of volume to be used by that pod. This tightly couples the volume kind with pod. However, at times it is better to not explicitly mention the Type of volume rather just provision a variety of storage and the Pods will make use of the storage which suits them best. This is handled through Persistent Volume and Persistent Volume Claim.
A Persistent Volume (PV) represents a storage that been provisioned by you. It is a resource in Kubernetes cluster and its lifetime is beyond those of pods in the cluster.
A Persistent Volume Claim (PVC) is a specification which requests for a storage to be used by Pod.
Hence, PV is a storage resource and PVC is a request for that resource.
- First, you provision a PV with details of actual storage.
- Next, you create a PVC specification which has details of storage request.
- A Kubernetes control loop tries to bind a PVC with any PV that matches.
- Kubernetes then mounts the bound volume to the Pod.
- When a user has no further need of the volume then they can delete the PVC. The PV specification mentions a reclaim policy which tells the cluster what to do when the volume has been released.
A PV specification is as follows:
capacity: specifies the size of volume.
volumeMode: use filesystem to use a file system or block for a raw block device.
accessMode: this can be
reclaimPolicy: This can be Retain, Recycle, or Delete.
Apply the above PV specification:
A PVC specification is as follows:
Apply the above PVC specification:
Now we can use this PV is our Pod specification as follows:
For enabling snapshots of a volume kubernetes provides
VolumeSnapshotContent is the snapshot of the content of a Volume while
VolumeSnapshot is a request for a snapshot. Just like a PVC is bound to a PV, the
VolumeSnapshot is bound to a
VolumeSnapshotContent. Here is a sample specification of both:
So far, we have created volumes manually, but in a managed environment it is highly recommended to have a facility where we can create volumes on-demand. Kubernetes provides Dynamic Volumes which eliminate the need to pre-provision volumes. To enable Dynamic Volumes we have to use a Kubernetes resource known as
StorageClass . This object specifies which storage provisioner is to be used and the associated parameters. For example, to use a SSD disk provided by Google Kubernetes Engine, create the following
Now create a
PersistentVolumeClaim which uses this
This automatically provisions an SSD like a persistent disk.
- Kubernetes Volumes offer storage which is persistent and lasts longer than lifetime of a container or even a pod.
- To decouple volume types with a pod specification use PVC and PV.
- To dynamically provision volumes use StorageClass.
This post has described all the above features with near real-life Kubernetes samples and they can be readily used in your projects.
Opinions expressed by DZone contributors are their own.