Kubernetes has many core abstractions, sometimes called primitives, that make the experience of deploying and managing applications so much better than what came before. Understanding these abstractions helps you take full advantage of Kubernetes and also avoid complexity—especially when running stateful applications like databases, data analytics, big data applications, streaming engines, machine learning, and AI apps.

In this article, I’ll review some of the fundamental abstractions in Kubernetes storage, and walk through how helps solve important challenges that arise with the need for persistent storage in Kubernetes.

Kubernetes abstractions and Kubernetes storage

The is a great example of a core Kubernetes abstraction. It’s actually the first example—the starting point.

Back in 2015, other container orchestration systems started with a single container as the fundamental abstraction; . A Pod is a group of one or more containers that need to run together to be useful. One simple analogy is that a Pod is like an outfit of clothing. It’s great to have a shirt and socks on, but let’s not walk out the door without pants!

Pods are like that—they let us focus on what’s needed to be useful (a running outfit) and not overload us with bookkeeping minutiae (a shoelace, one sock). Don’t get me wrong, the minutiae is being tracked by the scheduler and (the Kubernetes agent). But it’s this abstraction that allows for the ecosystem to build on Kubernetes and for administrators to automate their infrastructure. And today, we see that most other schedulers have adopted the Pods concept, a sure sign of its usefulness.