5 Storing data with volumes, mounts and claims
Data access in a clustered environment is difficult. Moving compute around is the easy part - the Kubernetes API is in constant contact with the nodes, and if a node stops responding then Kubernetes can assume it's offline and start replacements for all of its pods on other nodes. But if an application in one of those pods was storing data on the node, then the replacement won't have access to that data when it starts on a different node - and it would be disappointing if that data contained a very large order which a customer hadn't completed. You really need cluster-wide storage, so pods can access the same data from any node.
Kubernetes doesn't have built-in cluster-wide storage, because there isn’t a single solution which works for every scenario. Apps have different storage requirements, and the platforms which can run Kubernetes have different storage capabilities. Data is always a balance between speed of access and durability, and Kubernetes supports that by allowing you to define the different classes of storage which your cluster provides, and to request a specific storage class for your application. In this chapter you'll learn how to work with different types of storage and how Kubernetes abstracts away storage implementation details.