A volume in Kubernetes can be thought of as a directory that is accessible to the containers in a pod. In Kubernetes, we have different types of volumes, and the type determines how the volume is created as well as its content.
The concept of volume was present in Docker, but the volume was very much limited to a specific pod. As soon as the life of a pod ended, the volume was also lost. Volumes created by Kubernetes, on the other hand, are not limited to any container. It supports any or all containers deployed within the Kubernetes pod. The fact that Kubernetes volume supports different types of storage means that the pod can use multiple of them at the same time.
Processes running within pod containers see a file system view that includes:
1. A root file system that matches the content of the container image.
2. Volumes attached to the container (if defined). Within the container file system, each volume mounts on a unique path.
Volumes are defined in the .spec.containers[*].volumeMounts field of the pod template. For each pod and each container image within the pod you must specify which volumes and paths will be mounted (the paths can be different for each container).
Types of Volumes
Kubernetes supports multiple volumes, allowing each pod to use various volume types at the same time. Ephemeral volumes are limited to the lifetime of the pod, whereas persistent volumes can persist beyond the lifetime of the pod. It means that Kubernetes destroys ephemeral volumes when their pod no longer exists, while persistent volumes retain their data.
1. Persistent Volumes
Kubernetes includes a PersistentVolume subsystem and an API for storage provisioning and consumption. It works with two API resources: persistent volume (PV) and persistent volume claim (PVC) (PVC).
PersistentVolume (PV)
A PV is a storage resource that is part of a cluster. Administrators can manually provision PVs, and Kubernetes can dynamically provision PVs using storage classes. PVs, like volumes, are plugins, but their lifecycle is independent of any pod that uses them.
A PV is an API object that captures storage implementation details such as iSCSI, NFS, and cloud provider storage systems. It functions similarly to a node but provides storage resources rather than computing resources.
PersistentVolumeClaim (PVC)
A PVC is a user-created storage request. It functions similarly to a pod, but it uses PV resources instead of node resources. A PVC can specify size access modes such as ReadWriteOnce, ReadWriteMany, and ReadOnlyMany when requesting specific storage resources.
PVCs allow users to consume abstract storage resources, but for different problems, users typically require PVs with varying properties. This is why cluster administrators are frequently required to provide varying PVs that differ in more than just size and access modes. They are able to do so without exposing users to implementation details via StorageClass resources.
2. Ephemeral Volumes
Ephemeral volumes do not store data persistently across restarts. These volumes are bound to the lifetime of the pod, which means they are created and deleted along with it. It allows pods to be stopped and restarted without being constrained by the availability of persistent volume.
Ephemeral volumes are easy to set up and manage. You can specify them directly in the pod specification. Ephemeral volumes are ideal for applications such as caching services that do not require persistent storage.
3. EmptyDir Volumes
An emptyDir volume is created when Kubernetes assigns a pod to a node. This volume's lifespan is linked to the lifecycle of a pod on that node. When containers restart or crash, an emptyDir volume is recreated. However, when the pod is removed from the node, crashes, or dies, the data in this volume is deleted and lost. You can declare the volume type name as a field in the pod manifest file after creating an emptyDir volume. It appears in the volume property section with the value empty curly braces. EmptyDir volumes are best suited for storing temporary data.
4. Kubernetes hostPath Volumes
A hostPath volume mounts a directory or file from the filesystem of the host node into your pod. This is not something that most Pods will require, but it does provide a powerful escape hatch in some situations.
For example, some uses for a hostPath are:
- running a container that needs access to Docker internals; use a hostPath of /var/lib/docker
- running cAdvisor in a container; use a hostPath of /sys
- allowing a Pod to specify whether a given hostPath should exist prior to the Pod running, whether it should be created, and what it should exist as
5. Kubernetes Volumes ConfigMap
ConfigMaps allow you to inject configuration data into pods. ConfigMap data can be referenced in a volume of type configMap and consumed by containerized applications running in a pod. When referencing a ConfigMap, you must provide the name of the ConfigMap in the volume. Kubernetes allows you to change the path for a specific ConfigMap entry.
More information on volumes can be found in the official Kubernetes documentation.
This brings me to the end of this post.
Thank you for reading!
*** Explore | Share | Grow ***
Comments