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 key to understanding emptyDir volumes is recognizing that they're bound to the Pod's lifetime, not to individual containers. This is a subtle but critical distinction. When you define an emptyDir volume in your Pod specification, Kubernetes creates that volume when the Pod starts and destroys it when the Pod is deleted. Everything that happens to containers within that Pod — crashes, restarts, even complete container replacements — doesn't affect the volume because the volume exists at the Pod level.

Let's make this concrete. Imagine you have a Pod running with an emptyDir volume mounted at /cache. Your container writes a file called temp.data to that directory. If the container crashes due to a memory issue, Kubernetes will restart it (or start a new container instance), and when that new container comes up, it mounts the same emptyDir volume. The temp.data file is still there because the volume never went away — only the container restarted. This is the behavior we explored in the previous lesson.

Now imagine a different scenario. You decide to update your Pod configuration — maybe you're changing an environment variable or adding a new volume. Because most Pod specification fields are immutable (like environment variables and volume definitions), applying these changes requires replacing the existing Pod with a new one. This leads to Pod recreation, which is fundamentally different from a container restart. While a container restart happens within the existing Pod context (preserving the volume), recreation destroys the old Pod and creates a new one. Even if you use the exact same Pod name, the new Pod instance gets a brand new emptyDir volume. The old volume was destroyed when the old Pod was deleted, and all the data in it is permanently gone.

This lifecycle behavior is intentional and actually quite useful. It means volumes are perfect for temporary data that only needs to exist while a specific Pod instance is running. The data survives container-level problems (crashes, restarts, even complete container replacements within the same Pod), but it doesn't outlive the Pod itself. This makes ideal for scratch space, caches, and temporary processing buffers — scenarios where you want resilience against container failures but don't need long-term persistence.

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 .

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:

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:

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:

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:

You should see output confirming the Pod was created:

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

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:

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

You'll see confirmation that the Pod is being 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:

Again, you'll see:

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

The emptyDir volume type provides Pod-scoped temporary storage that strikes a useful balance between reliability and cleanup. Data stored in an emptyDir volume survives container crashes and restarts because the volume is attached to the Pod, not to individual containers. However, that same data is completely lost when the Pod is deleted or recreated because the volume's lifecycle is bound to the Pod's lifecycle.

This makes emptyDir perfect for temporary "scratch" work — caches, processing buffers, build artifacts, and any other data that needs to be resilient during a job but doesn't need to persist afterward. In the upcoming practice exercises, you'll experiment with this lifecycle yourself, creating Pods with emptyDir volumes, writing data to them, and observing how that data behaves through container restarts and Pod deletions.