Kubernetes Volumes Basics

Introduction to Kubernetes Volumes

When you run applications in Kubernetes, you're working with containers that are designed to be lightweight and portable. By default, these containers treat storage as temporary — any files you create or modify inside a container exist only as long as that specific container instance is running. This works fine for stateless applications, but what happens when you need to save logs, store user uploads, or persist database files? That's where Kubernetes volumes come in. In this lesson, we'll explore why containers need volumes, how to define them in your Pod specifications, and the crucial difference between declaring a volume and actually using it.

The Container Storage Problem

Containers use what's called an ephemeral filesystem . This means that when you write a file inside a running container, that file is stored in a temporary layer that's tied to that specific container instance. Everything works fine until something causes the container to restart — maybe it crashes. When the container restarts, Kubernetes creates a fresh container instance, and all the data from the previous instance disappears. Let's make this concrete with a real-world scenario. Imagine you're running a web application that allows users to upload profile pictures. Without volumes, here's what happens: a user uploads their photo, your application saves it to /var/www/uploads/profile.jpg inside the container, and everything looks great. An hour later, the container restarts due to a memory issue. When the new container starts up, the /var/www/uploads directory is empty — the user's profile picture is gone. This same problem affects application logs, cached data, and any other files your application creates. This ephemeral behavior is actually intentional in container design. It keeps containers lightweight and ensures they start from a clean, predictable state. But for many real applications, we need a way to preserve data across container restarts. That's the fundamental problem that volumes solve.

Kubernetes Volumes: The Two-Part Solution

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Example: Pod With an emptyDir Volume

Now let's look at a Pod that uses a volume to provide persistent storage across container restarts. Here's the complete specification:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: app-with-volume
spec:
  containers:
    - name: app
      image: nginx:1.25
      volumeMounts:
        - name: scratch
          mountPath: /tmp/data
  volumes:
    - name: scratch
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: app-with-volume
spec:
  containers:
    - name: app
      image: nginx:1.25
      volumeMounts:
        - name: scratch
          mountPath: /tmp/data
  volumes:
    - name: scratch
      emptyDir: {}

This Pod has the same basic structure as our previous example, but now we've added the two-part volume configuration. Let's break down each part to understand how they work together.

First, look at the spec.volumes section at the bottom of the file:

YAML

  volumes:
    - name: scratch
      emptyDir: {}

  volumes:
    - name: scratch
      emptyDir: {}

This section defines a volume. We're telling Kubernetes, "Create a volume, call it scratch, and make it an emptyDir type." The emptyDir: {} syntax means we're using all the default settings for this volume type (Kubernetes will create an empty directory on the node's disk). The name scratch is arbitrary — we could call it data, storage, or my-volume — but it needs to be unique within this Pod because we'll use this name to reference the volume later.

Now look at the volumeMounts section inside the container definition:

YAML

      volumeMounts:
        - name: scratch
          mountPath: /tmp/data

      volumeMounts:
        - name: scratch
          mountPath: /tmp/data

This section mounts the volume into the container's filesystem. The name: scratch field connects this mount to the volume we defined earlier — the names must match exactly. The mountPath: /tmp/data field specifies where the volume appears inside the container. After this Pod starts, the nginx container will see a directory at /tmp/data, and anything written to that directory will actually be stored in the scratch volume.

Here's the crucial point: the volume exists at the Pod level, but it's accessed through the container's filesystem. When the nginx container writes a file to /tmp/data/myfile.txt, that file is stored in the scratch volume. If the container crashes and Kubernetes restarts it, the new container instance will mount the same scratch volume at /tmp/data, and myfile.txt will still be there. The data survives because it's stored in the volume, not in the container's ephemeral filesystem.

Working with Volume-Based Pods

Now that we understand the YAML structure, let's look at the commands you'll use to work with these Pods. On CodeSignal, these commands are ready to run in the terminal, and all the necessary tools are pre-installed.

To create both Pods, use the kubectl apply command:

Shell

kubectl apply -f pod-no-volume.yaml
kubectl apply -f pod-with-volume.yaml

kubectl apply -f pod-no-volume.yaml
kubectl apply -f pod-with-volume.yaml

When you run these commands, you should see output like this:

text

pod/app-without-volume created
pod/app-with-volume created

pod/app-without-volume created
pod/app-with-volume created

This confirms that Kubernetes has accepted your Pod specifications and is working to create the Pods. The Pods will go through a brief initialization phase during which Kubernetes pulls the nginx image (if it's not already cached) and starts the containers.

To inspect the Pods and verify the volume configuration, use the kubectl describe command:

Shell

kubectl describe pod app-without-volume
kubectl describe pod app-with-volume

kubectl describe pod app-without-volume
kubectl describe pod app-with-volume

The describe output is detailed, but focus on two sections. For app-without-volume, you'll see a Containers section that lists the nginx container, but there won't be any Mounts listed (or only the default Kubernetes service account token). For app-with-volume, you'll see a Mounts section under the container that shows:

text

Mounts:
  /tmp/data from scratch (rw)

Mounts:
  /tmp/data from scratch (rw)

This confirms that the scratch volume is mounted at /tmp/data with read-write permissions. You'll also see a Volumes section near the bottom of the output that shows:

text

Volumes:
  scratch:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)

Volumes:
  scratch:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)

This confirms that the volume is defined and identifies its type. These describe outputs are valuable for troubleshooting — if your volume isn't working as expected, this is where you'll spot configuration issues.

When you're done experimenting, clean up the Pods with the kubectl delete command:

Shell

kubectl delete -f pod-no-volume.yaml
kubectl delete -f pod-with-volume.yaml

kubectl delete -f pod-no-volume.yaml
kubectl delete -f pod-with-volume.yaml

You'll see confirmation that the Pods are being deleted. When a Pod with volumes is deleted, the volumes are also removed. For emptyDir volumes, this means the data is permanently lost — emptyDir is designed for temporary storage that only needs to outlive container restarts, not Pod deletions.

Introduction to Kubernetes Volumes

The Container Storage Problem

Kubernetes Volumes: The Two-Part Solution

Join the 1M+ learners on CodeSignal

Example: Pod Without a Volume

Example: Pod With an emptyDir Volume

Mounting the Same Volume at Multiple Paths

Working with Volume-Based Pods

Summary and Practice Preview