Kubernetes Ephemeral volumes

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–

1. The emptyDir ephemeral volume
2. 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 —

1. We can bind the volumes by fixed sizes that the Pods cannot exceed during the application’s run.
2. It can some initial level of data into the volume while creation.
3. 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! 🙂