emptyDir Volume Lifecycle

Beyond Container Restarts

In the previous lesson, we learned that Kubernetes volumes solve the container storage problem by providing storage that persists across container restarts. We saw how an emptyDir volume keeps data safe even when a container crashes and Kubernetes spins up a replacement. But there's a crucial question we haven't answered yet: what happens when the Pod itself is deleted? This distinction matters because, in real Kubernetes environments, Pods get deleted and recreated all the time — during deployments, scaling operations, node maintenance, or when you're simply updating your application configuration. In this lesson, we'll explore the lifecycle boundaries of emptyDir volumes and learn exactly when your data persists and when it disappears.

The Pod-Level Lifecycle of emptyDir

Join the 1M+ learners on CodeSignal

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

When emptyDir Makes Sense

Understanding the lifecycle helps us identify the right use cases for emptyDir volumes. These volumes shine in scenarios where you need temporary storage that's more reliable than a container's ephemeral filesystem but doesn't need to persist beyond the Pod's lifetime. One common use case is caching. Imagine a data processing application that downloads a large dataset, transforms it, and then uploads the results. The raw downloaded data doesn't need to persist forever — it's just needed during the processing run. An emptyDir volume gives you a place to store that data where it won't disappear if the processing container crashes halfway through, but it will be cleaned up automatically when the Pod completes.

Another excellent use case is scratch space for data transformations. Consider a video encoding service that receives a video file, transcodes it to multiple formats, and then uploads the results to cloud storage. During the encoding process, the application might generate temporary files — partially encoded chunks, metadata files, or intermediate formats. These files need to survive if the encoder process crashes (so you don't lose hours of encoding work), but they're useless once the job completes. An emptyDir volume provides exactly this behavior: resilience during the job, automatic cleanup afterward.

Build processes are another natural fit. In a CI/CD pipeline, you might have a Pod that checks out source code, compiles it, runs tests, and produces build artifacts. The compilation process might generate thousands of temporary object files and intermediate build products. These files need to be available throughout the build process (and need to survive if the compiler crashes), but they're worthless once the final artifacts are produced. An emptyDir volume gives you fast, reliable scratch space without cluttering your persistent storage with temporary build debris.

However, emptyDir is not appropriate for data that needs to outlive the Pod. User-uploaded content like profile pictures, documents, or media files should never go in an emptyDir volume because they'll be lost the next time you deploy an update. Database files are another clear no-go — if your database Pod gets deleted and recreated, you don't want to lose all your data. Application logs that need long-term retention for compliance or debugging also need a more permanent storage solution. The rule of thumb is simple: if you'd be upset to lose the data when the Pod is deleted, don't use emptyDir.

A Data Processor with Scratch Space

Let's look at a realistic example that demonstrates when emptyDir is the right choice. We'll create a Pod that simulates a data processing job — the kind of workload that generates temporary cache files during processing but doesn't need to keep them forever. Here's the complete Pod specification:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: data-processor
spec:
  containers:
    - name: processor
      image: busybox:1.35
      command: ['sh', '-c', 'echo "processing-data" > /cache/temp.file && sleep 3600']
      volumeMounts:
        - name: cache-volume
          mountPath: /cache
  volumes:
    - name: cache-volume
      emptyDir: {}

apiVersion: v1
kind: Pod
metadata:
  name: data-processor
spec:
  containers:
    - name: processor
      image: busybox:1.35
      command: ['sh', '-c', 'echo "processing-data" > /cache/temp.file && sleep 3600']
      volumeMounts:
        - name: cache-volume
          mountPath: /cache
  volumes:
    - name: cache-volume
      emptyDir: {}

Let's break down this specification to understand what each part does. The metadata.name field gives our Pod the name data-processor, which we'll use in our kubectl commands. The Pod runs a single container called processor using the busybox image — a lightweight Linux environment that's perfect for demonstrating basic concepts.

The interesting part is the command field:

YAML

      command: ['sh', '-c', 'echo "processing-data" > /cache/temp.file && sleep 3600']

      command: ['sh', '-c', 'echo "processing-data" > /cache/temp.file && sleep 3600']

This command simulates a data processing job. It writes the string "processing-data" to a file called /cache/temp.file, then sleeps for 3600 seconds (one hour) to keep the container running. In a real application, this might be a Python script that downloads data, processes it, and writes intermediate results to the cache directory. The key point is that the application is writing to /cache, which is where we'll mount our volume.

Now look at the volume configuration. First, we define the volume at the Pod level:

YAML

  volumes:
    - name: cache-volume
      emptyDir: {}

  volumes:
    - name: cache-volume
      emptyDir: {}

This creates an emptyDir volume named cache-volume. The empty braces {} mean we're using all the default settings — Kubernetes will create an empty directory on the node's disk when the Pod starts. Then we mount this volume into the container:

YAML

      volumeMounts:
        - name: cache-volume
          mountPath: /cache

      volumeMounts:
        - name: cache-volume
          mountPath: /cache

This makes the cache-volume appear at /cache inside the container. When the container's command writes to /cache/temp.file, that file is actually stored in the emptyDir volume, not in the container's ephemeral filesystem. This means the file will survive if the container crashes and restarts, but it will be lost if the Pod is deleted.

Testing the Lifecycle: Delete and Recreate

Now let's run through a sequence of commands that demonstrates the emptyDir lifecycle. Save the YAML above to a file called pod-scratch-space.yaml, then create the Pod:

Shell

kubectl apply -f pod-scratch-space.yaml

kubectl apply -f pod-scratch-space.yaml

You should see output confirming the Pod was created:

text

pod/data-processor created

pod/data-processor created

Wait a few seconds for the Pod to start, then verify that the cache file was created:

Shell

kubectl exec -it data-processor -- cat /cache/temp.file

kubectl exec -it data-processor -- cat /cache/temp.file

The kubectl exec command runs a command inside the running container. In this case, we're using cat to read the contents of the file. You should see:

text

processing-data

processing-data

This confirms that the container successfully wrote to the emptyDir volume. Now here's where it gets interesting. Let's delete the Pod:

Shell

kubectl delete -f pod-scratch-space.yaml

kubectl delete -f pod-scratch-space.yaml

You'll see confirmation that the Pod is being deleted:

text

pod "data-processor" deleted

pod "data-processor" deleted

When this command completes, the Pod is gone, and so is the emptyDir volume. The temp.file we created no longer exists anywhere in the cluster. Now let's recreate the Pod using the exact same YAML file:

Shell

kubectl apply -f pod-scratch-space.yaml

kubectl apply -f pod-scratch-space.yaml

Again, you'll see:

text

pod/data-processor created

pod/data-processor created

This looks identical to our first apply command, but something important has changed. Wait a few seconds for the Pod to start, then check the cache directory:

Shell

kubectl exec -it data-processor -- ls /cache/

kubectl exec -it data-processor -- ls /cache/

You should see:

text

temp.file

temp.file

Wait, the file is there? Yes, but it's not the same file as before. When we recreated the Pod, the container's command ran again, creating a new temp.file. To prove this is a new emptyDir volume and not the old one, let's try a different test. Delete the Pod again:

Shell

kubectl delete -f pod-scratch-space.yaml

kubectl delete -f pod-scratch-space.yaml

Now modify the YAML to change the command so it doesn't create the file. Change the command line to:

YAML

      command: ['sh', '-c', 'sleep 3600']

      command: ['sh', '-c', 'sleep 3600']

Apply this modified version:

Shell

kubectl apply -f pod-scratch-space.yaml

kubectl apply -f pod-scratch-space.yaml

Wait for the Pod to be running, then check the cache directory:

Shell

kubectl exec -it data-processor -- ls /cache/

kubectl exec -it data-processor -- ls /cache/

You'll see an empty directory — no output at all. This proves that each time you delete and recreate the Pod, you get a completely fresh emptyDir volume. The data from the previous Pod instance is gone forever. This is the key insight: same Pod name, same YAML configuration, but brand new storage.

emptyDir Volume Lifecycle

Beyond Container Restarts

The Pod-Level Lifecycle of emptyDir

Join the 1M+ learners on CodeSignal

When emptyDir Makes Sense

A Data Processor with Scratch Space

Testing the Lifecycle: Delete and Recreate

Summary and Practice Preview