Persistence with Kubernetes

So far, all our examples, and even code, have been essentially stateless. In the last chapter, we introduced a container using Redis, but didn't specify anything special for it. By default, Kubernetes will assume any resources associated with a pod are ephemeral, and if the node fails, or a deployment is deleted, all the associated resources can and will be deleted with it.

That said, almost all the work we do requires storing and maintaining state somewhere—a database, an object store, or even a persistent, in-memory queue. Kubernetes includes support for persistence, and as of this writing, it's still changing and evolving fairly rapidly.

Volumes

The earliest support in Kubernetes was for volumes, which can be defined by the cluster administrator, and we've already seen some variations of this construct with the configuration being exposed into a container using the Downward API back in Chapter 4, Declarative Infrastructure.

Another kind of volume that can be easily...