Updated April 12, 2023
Introduction to Kubernetes Volume
Kubernetes volume is a directory or a container’s file system, which has a customizable information store. It is a function as a single point from which kubernetes can allocate resources and services throughout the network distribution. This customizable information store also gives administration access to managing its objects and their attributes at a single point. The Kubernetes lifecycle depends as long as the container is alive. This file system is available until the Container terminates and restarts. Kubernetes volumes are useful for storing temporary data as per the existence of pods. If necessary, the information store can be distributed among many pods differently. As the kubernetes volume is a file system that acts as an administrator, it can easily search for information from various pods throughout the network.
Types of Kubernetes Volume
1. Local-Node directory memory: The Local-node memory is attached to the pod, it is either stored in RAM or persistent storage. Due to their pod dependency, as the pod is running their content is available to use. The data is lost if it goes down.
For example, The emptyDir and hostPath are attached to the pod, stored either in storage or RAM.
2. Cloudstorage volumes: This type of volume placed outside of the pod which is independent of the application. it is used to preserve data. it has a lot of disadvantages over advantages. Please find the list below:-
- It is difficult to handle because of their communication
- The user must have sufficient knowledge about the storage before connecting to the Pod.
For example: – gcePersistentDisk, awsElasticBlockStore.
3. File-sharing volumes: In this volume type, the NFS is used to connect with volume through the YAML file. Initially, the content of the volume is unmounted to use but it’s available. Unlike the emptydir in NFS, the volume exists even the pod s not available.
4. Distributed-file systems: This type of volume has to be mounted into your pods. This volume can be pre-populated with data, and that data can be handed to respective Pods. For Example: glusterfs
Please find below yaml used for glusterfs:-
apiVersion: v1
kind: Pod
metadata:
name: glusterfs
spec:
containers:
- name: glusterfs
image: nginx
volumeMounts:
- mountPath: "/mnt/glusterfs"
name: glusterfsvol
volumes:
- name: glusterfsvol
glusterfs:
endpoints: glusterfs-cluster
path: kube_vol
readOnly: truePlease find the output below:-
5. Special volume types: Persistent volume and PersistentVolumeClaim is special kind of volume which mainly used in kubernetes clusters.
Persistent volume (PV) is the piece of storage that has physical existence in the host machine to store your persisted data. The main feature of a PV is that it has an independent life cycle, and it continues to live when the pods accessing it have shut down. Each PV contains a spec and status, which is the specification and status of the volume. Please find the example below:-
apiVersion: v1
kind: PersistentVolume
metadata:
name: cba
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
nfs:
path: /temp
server: 127.0.0.1Please find the output below:-
PV will have a specific storage capacity. This is set using the PV’s capacity attribute.
Persistent volume (PV) Access Mode
Each volume is supported by the specific mode of access modes given by PV. Please find the access modes details below:-
The different available access modes are:
ReadWriteOnce – If there is a single node, the volume can be mounted as read-write by the only node
ReadOnlyMany – If there is many nodes, the volume can be mounted read-only by many other nodes
ReadWriteMany – if there is any node the volume can be mounted as read-write by many other nodes.
Phases of volume
Available – If the free resources of the volume is not ready to claim, such a state of the volume is in the available state.
Bound – When the volume is bound to a claim by PersistentVolumeClaim. Such a state of volume is considered a bound state.
Released – When the volume resources are not available in the cluster, although the existing claim has been deleted. In this case, the volume is considered as in the Released state.
Failed – A volume is considered as in the failed state if the volume has failed to claim by its automatic process.
A persistent volume claim is a kind of request for the platform to create a Persistent volume in the applications. The communication between Persistent volume (PV) and Persistent volume claim (PVC) used to happen by their lifecycle process. Kubernetes looks for the condition defined in PVC and if there is one, it matches the claim to PV. This is called binding. We can provision the Persistent volume (PV) in two ways:-
Static – the cluster administration use to create the volume assign statically in the yaml file. The administration carries information about the storage which is available for cluster users.
Dynamic – Clusters used to try dynamically provision the volume once the administrator created to match a user’s PersistentVolumeClaim. The pods can access storage by claiming volume. The pod’s namespace and their claim use to find by the cluster so that PersistentVolume can claim easily. The volume is then available to the host as well as the pod.
Please find the Configurations for Persistent volume claim (PVC)
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: claimVol
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8GisFind the output below:-
Each PVC has a specification and status of the claim. Whenever PVC requested storage with specific access modes, Claims uses the same conventions as volumes.
The Lifecycle of a Volume and Claim
Provisioning: A cluster administrator will create several PVs. They carry the details of the storage which is available for use.
Binding: A user creates a PersistentVolumeClaim with a specific amount of storage requested by using any of its access modes.
Using: Pods usually do claim for their volumes. The cluster inspects the claim to find the bound volume and mounts the same for a pod.
Releasing: When a user is done with their volume, they can delete the PVC objects from the API which allows reclamation of the resource.
Reclaiming: The reclaim policy for a PersistentVolume tells the cluster what to do with the volume after it has been released.
Recommended Articles
We hope that this EDUCBA information on “Kubernetes Volume” was beneficial to you. You can view EDUCBA’s recommended articles for more information.
