Hello, readers! In this article, we will be focusing on some of the Kubernetes Ephemeral Volumes, in detail.
So, let us begin! 馃檪
What is Ephemeral Volume?
Kubernetes provides us with various resources to provision and orchestrate the applications hosted through containers in the Pod resources. Attached to it at the back-end, we definitely need to have a storage associated with the moving data values at static and dynamic run of the flow of the application.
In our previous article, we emphasized and explored about Kubernetes Persistent Volume and Persistent Volume Claims to store the data at back-end. Persistent Volumes stay even if the Pod gets deleted. So, ideally, we would need persistent volumes only when we want some data from the application to persist and stay irrespective of the health of the Pod.
But we may want data to be attached to our application as long as the pod lasts. For example, the stdout stderr logs generated by the application, cache data generated by the application, etc. does not necessarily need Persistent Volume bound to the application.
For the above scenario, Kubernetes provides us with Ephemeral Volumes.
Ephemeral Volumes last as long as the application within the Pod does. That is, they are volatile in nature. The moment a Pod of the application drains out, the related ephemeral storage would be wiped off.
In the course of this topic, we would be having a look at the below types of Ephemeral Volumes–
- The emptyDir ephemeral volume
- Generic Ephemeral Volume
1. The emptyDir ephemeral volume
The emptyDir kind of volume will come into picture when a Pod gets live. This kind of volume, being ephemeral in nature, lasts as long as the Pod is up and healthy. Also, the volume is initially empty as the pod gets created.
To note, incase the container crashes, our emptyDir volume is still preserved as the volume is associated with the Pod not the container directly. Every container has the permission to read and write files to the emptyDir volume thoroughly.
Let us have a look at the emptyDir volume YAML schema-
Here, we have created a Pod and assigned emptyDir volume to it.
apiVersion: v1
kind: Pod
metadata:
name: demo-pod
spec:
containers:
- image: gcr.io/hello-world:1.0
name: demo-con
volumeMounts:
- mountPath: /cache/data
name: vol
volumes:
- name: vol
emptyDir: {}
2. Generic Ephemeral Volumes
Generic ephemeral volumes resemble the emptyDir volumes along with the below extra features —
- We can bind the volumes by fixed sizes that the Pods cannot exceed during the application’s run.
- It can some initial level of data into the volume while creation.
- We can prefer the storage based on the local storage or network attached storage.
Let us have a look at the Generic Ephemeral Volume YAML schema–
As seen below, we have here requested for 2Gi of storage space within the generic volume associated to the Pod. It even allows us to have different types of access modes applied on the volumes such as ReadWriteOnce, ReadWriteMany, etc.
kind: Pod
apiVersion: v1
metadata:
name: demo
spec:
containers:
- name: hello-world
image: busybox
volumeMounts:
- mountPath: "/data"
name: data-volume
volumes:
- name: data-volume
ephemeral:
volumeClaimTemplate:
metadata:
labels:
type: demo-volume
spec:
accessModes: [ "ReadWriteMany" ]
storageClassName: "data-storage-class"
resources:
requests:
storage: 2Gi
Conclusion
By this, we have come to the end of this topic. Feel free to comment below, in case you come across any question. For more such posts related to Kubernetes, Stay tuned with us!
Till then, Happy learning! 馃檪