Kubernetes, or K8s, is an open-sourced container orchestration technology that is used to automate the manual processes of deploying, managing, and scaling applications by the help of containers. Kubernetes uses a single container per pod, which is great for most stateless applications, but some applications require more than one container to work together and require some way to persist data and share storage between pods. Sharing storage between containers in a Kubernetes cluster can be achieved with the help of Kubernetes volumes. A volume in Kubernetes is a data-storing feature with the help of which we can store persistent data that can be accessed by containers in a Kubernetes pod. In this article, we will discuss how to share storage between containers in a Kubernetes cluster using volumes.

Tutorial-How to Share Storage Between Containers?

Follow this step-by-step guide to understand how to share storage between containers in a Kubernetes cluster.

Step 1: Starting a Kubernetes cluster

You can skip this step if you already have a Kubernetes cluster running on your machine. But in case you don’t have a cluster running, enter the following command to create Kubernetes locally using Minikube:

minikube start

Minikube is a one-node Kubernetes cluster where master processes and work processes both run on one node.

Step 2: Creating a configuration file

Here we will create a basic application that use Debian image to write a simple “Hello world” HTML file and mounts it as index.html file on the nginx server. Create a file called example-app.yaml

touch example-app.yaml

and enter the following code inside it:

apiVersion: v1
kind: Pod
metadata:
  name: shared-storage-example
spec:
  volumes:
    - name: shared-data
      emptyDir: {}
  containers:
    - name: container-1
      image: nginx
      volumeMounts:
        - name: shared-data
          mountPath: /usr/share/nginx/html
    - name: container-2
      image: debian
      volumeMounts:
        - name: shared-data
          mountPath: /data
      command: ["/bin/sh"]
      args: ["-c", "echo Hello world > /data/index.html"]

Through this configuration file we are creating two containers – container-1 and container-2. container-1 use an nginx image while container-2 uses a debian image. We have created a shared a Volume of type emptyDir and named it “shared-data”. And this Vloume is shared between the container-1 and container-2. container-1 mounts the volume at /usr/share/nginx/html while container-2 mounts it at /data.

Step 3: Applying the configuration file

Now when we apply the configuration file to create Pod by entering the following command:

kubectl apply -f example-app.yaml

It will take some time when the container-2 will write “Hello world” to shared-data and it will then exit. And when we curl inside the container-1, the nginx will return “Hello world” because of the index.html file mounted to the root directory.

If we check the list of Pods by the following command:

kubectl get pods

We will see that one container is ready while other in not.

Step 4: Checking the state of the Pod

Now when we check the state of the Pod using the following command:

 kubectl get pod shared-storage-example --output=yaml

You will get a similar output and we can see that container-2 is terminated, while container-1 is still running:

Step 5: Getting output from container-1

Now we know that container-2 has terminated, but since we have shared storage, we can also get the output “Hello world” using the container-1. For that we will get inside the terminal for container-1 by using the following command:

kubectl exec -it shared-storage-example -c container-1 -- /bin/bash

and we have entered the bash terminal for container-1:

Inside the terminal for container-1, we can curl the server in order to get the response from the webpage:

curl localhost

And we will get the output of a webpage with the text “Hello world”:

This is how we can have shared storage where even after container-2 had terminated, we could access the data using container-1. Pat yourself on the back because we have just learned how to share storage between Containers in a Kubernetes cluster.

How does Kubernetes storage work?

Volumes

A Volume in Kubernetes is a data storing feature with the help of which we can store data that is persistent and can be accessed by containers in a Kubernetes pod. Consider a case where an application is using a MySQL database Pod. The Data gets added, updated or deleted in the database but by default in Kubernetes when you restart the Pod all those changes will be gone because Kubernetes doesn’t give you data persistence out of the box. To solve this data persistence issue we need Kubernetes Volume that doesn’t depend on the Pod lifecycle which will still be there when Pod dies and new one gets created so that the new Pod can pick up where the previous Pod left off.

How Volumes do this is that it basically attaches a physical storage on a hard drive to your Pod. That storage could be either on a local machine (meaning on the same server node where the Pod is running) or it could be on a remote storage (meaning outside of the Kubernetes cluster).

Persistent Volumes

A PersistentVolume is a piece of storage in a Kubernetes cluster that an administrator has provisioned. PersistentVolume has a Pod independent lifecycle so it can preserve state even after a Pod dies and a new Pod is created. PersistentVolume (PV) is a Kubernetes cluster resource just like a node. A Pod is immutable therefore, when it dies, all the data created during its lifetime will be lost. Most of the applications require this characteristic of Pod but sometimes applications (for example, database applications) needs to preserve state and that is where Kubernetes PersistentVolumes (PVs) are used by the cluster administrator which can store information persistently unaffected even after Pod dies and new Pod is created.

Three important Characteristics of Kubernetes Persistent Volumes are:

1. Persistent Volumes do not depend on the pod lifecycle.
2. Persistent Volumes are available on all nodes.
3. Persistent Volumes survives even if cluster crashes.

Static vs. Dynamic Provisioning