100 Days of DevOps: Day 54

Mastering Shared Volumes in Kubernetes

In the world of container orchestration, enabling containers to communicate and share data efficiently is a common requirement. One powerful feature Kubernetes offers is the ability to share storage volumes between containers within the same Pod. Today, we'll walk through a real-world scenario where we set up a shared emptyDir volume for two containers.

The Mission: Sharing Temporary Data

The objective is straightforward:

1. Create a Pod named volume-share-xfusion.
2. Deploy two containers within this Pod, both using the fedora:latest image.
3. Define a shared volume named volume-share using the emptyDir type.
4. Mount this shared volume to different paths in each container: /tmp/beta in the first and /tmp/apps in the second.
5. Verify that data written from one container is immediately accessible in the other.

The Solution:

The heart of the solution lies in a well-defined YAML manifest. The emptyDir volume is declared once at the Pod level, and then volumeMounts are specified within each container's definition to link to it.

Here is the final pod.yaml file:

apiVersion: v1
kind: Pod
metadata:
  name: volume-share-xfusion
spec:
  # Define the shared volume at the Pod level
  volumes:
  - name: volume-share
    emptyDir: {}
  containers:
  - name: volume-container-xfusion-1
    image: fedora:latest
    command: ["/bin/sh", "-c", "sleep 3600"]
    # Mount the shared volume into this container
    volumeMounts:
    - name: volume-share
      mountPath: /tmp/beta
  - name: volume-container-xfusion-2
    image: fedora:latest
    command: ["/bin/sh", "-c", "sleep 3600"]
    # Mount the same shared volume here
    volumeMounts:
    - name: volume-share
      mountPath: /tmp/apps

Why this works: An emptyDir volume is created when the Pod is assigned to a node. It's initially empty and shares the Pod's lifecycle. Since both containers mount the same volume-share, they are essentially accessing the same directory on the host node's filesystem, making it a perfect tool for sharing temporary files.

---

Execution and Verification

With the manifest ready, let's bring the pod to life and test the setup with a few simple commands.

1. Deploy the Pod:
   

   kubectl apply -f pod.yaml
   

   Output: pod/volume-share-xfusion created

2. Create a test file in the first container:
   Use kubectl exec to run a command inside our first container, creating a file in its mounted directory.
   

   kubectl exec -it volume-share-xfusion -c volume-container-xfusion-1 -- bash -c 'echo "Shared volume test" > /tmp/beta/beta.txt'
   

3. Verify the file in the second container:
   The moment of truth! I checked the corresponding mounted directory in the second container.
   

   kubectl exec -it volume-share-xfusion -c volume-container-xfusion-2 -- ls /tmp/apps
   

   Output: beta.txt

Success! The presence of beta.txt in the second container instantly confirmed that the shared volume was configured and working perfectly.

This exercise is a fantastic demonstration of how Kubernetes abstracts complex storage operations, allowing developers to build tightly-coupled, multi-container applications with ease.