Now let’s talk about the emptyDir Volume. It is considerably different from those we explored thus far.

An emptyDir Volume is created when a Pod is assigned to a node. It will exist for as long as the Pod continues running on that server.

What that means is that emptyDir can survive container failures. When a container crashes, a Pod is not removed from the node. Instead, Kubernetes will recreate the failed container inside the same Pod and, thus, preserve the emptyDir Volume. All in all, this Volume type is only partially fault-tolerant.

If emptyDir is not entirely fault-tolerant, you might be wondering why we are discussing it in the first place.

The emptyDir Volume type is the closest we can get to fault-tolerant volumes without using a network drive. Since we do not have any, we had to resort to emptyDir as the closest-we-can-get-to-fault-tolerant-persistence type of Volume.

As you start deploying third-party applications, you’ll discover that many of them come with the recommended YAML definition. If you pay closer attention, you’ll notice that many are using the emptyDir Volume type. It’s not that emptyDir is the best choice, but that it all depends on your needs, your hosting provider, your infrastructure, and quite a few other things.

There is no one-size-fits-all type of persistent and fault-tolerant Volume type. On the other hand, emptyDir always works. Since it has no external dependencies, it is safe to put it as an example, with the assumption that people will change to whichever type fits them better.

There is an unwritten assumption that emptyDir is used for testing purposes, and will be changed to something else before it reaches production.

As long as we’re using Minikube or k3d to create a Kubernetes cluster, we’ll use emptyDir as a solution for persistent volumes. Do not despair. Later on, once we move into a “more serious” cluster setup, we’ll explore better options for persisting state.

Now let’s talk about the emptyDir Volume. It is considerably different from those we explored thus far.

An emptyDir Volume is created when a Pod is assigned to a node. It will exist for as long as the Pod continues running on that server.

What that means is that emptyDir can survive container failures. When a container crashes, a Pod is not removed from the node. Instead, Kubernetes will recreate the failed container inside the same Pod and, thus, preserve the emptyDir Volume. All in all, this Volume type is only partially fault-tolerant.

If emptyDir is not entirely fault-tolerant, you might be wondering why we are discussing it in the first place.

The emptyDir Volume type is the closest we can get to fault-tolerant volumes without using a network drive. Since we do not have any, we had to resort to emptyDir as the closest-we-can-get-to-fault-tolerant-persistence type of Volume.

As you start deploying third-party applications, you’ll discover that many of them come with the recommended YAML definition. If you pay closer attention, you’ll notice that many are using the emptyDir Volume type. It’s not that emptyDir is the best choice, but that it all depends on your needs, your hosting provider, your infrastructure, and quite a few other things.

There is no one-size-fits-all type of persistent and fault-tolerant Volume type. On the other hand, emptyDir always works. Since it has no external dependencies, it is safe to put it as an example, with the assumption that people will change to whichever type fits them better.

There is an unwritten assumption that emptyDir is used for testing purposes, and will be changed to something else before it reaches production.

As long as we’re using Minikube or k3d to create a Kubernetes cluster, we’ll use emptyDir as a solution for persistent volumes. Do not despair. Later on, once we move into a “more serious” cluster setup, we’ll explore better options for persisting state.