Container storage is a hot area right now. But it’s a new frontier, so there is some degree of confusion around what’s on offer and supplier marketing can be a little hazy.
It’s accepted that most containerised applications in the enterprise require persistent storage, but it’s not always that easy to nail down exactly how a supplier’s container storage works. An emerging variant, and what would appear to be the holy grail for various reasons, is container-native storage, sometimes known as cloud-native storage.
Why the holy grail? Because it is the form of container storage that most conforms to the overall ethos behind containerisation. That is, everything that is required to manage storage can be encapsulated in containers and run from Kubernetes. It’s essentially a form of software-defined storage that runs in containers.
In other words, it is storage that, like any other service that forms part of the overall application landscape, can be delivered by code and is portable with the application, with no hardware dependencies.
That is important for a few reasons, and key among them is the influence of the cloud to the way IT is heading. Increasing use of hybrid- and multicloud working means the ability to move workloads between datacentre and cloud locations is essential.
Subsidiary reasons include an increasing need to make storage one of the things that developers provision by code and/or clicks, rather than submitting a ticket.
Container storage fundamentals
The fundamentals of persistent Kubernetes storage are based around a set of application programming interfaces (APIs). Firstly, persistent volume claims (PVCs) made by applications. These live with the application’s containers and travel with it to specify capacity required, tier of storage, and so on.
Meanwhile, there are persistent volumes (PVs) and storage classes, which are attributes of the storage itself, describing the nature of the persistent storage available and matching it to application PVCs in Kubernetes.
That storage can be local to the servers on which the Kubernetes cluster runs, or external, in a storage array, perhaps. If the storage is resident on external shared storage, it could be provisioned to containerised applications by plugins such as CSI (container storage interface).
So what is container-native storage?
Taking into account what we’ve described so far, and in particular the ethos of cloud-native operations and containerisation, there is a fundamental concept that should define container-native storage.
That is, that storage should be managed from the Kubernetes cluster to genuinely qualify as container-native, and be aggregated from media directly accessible to the cluster (something like Rook, perhaps?).
Meanwhile, to begin to compete with the feature set offered by mature storage products, container-native storage products should also include storage services such as replication, snapshots, data reduction, quality of service and encryption, but those aren’t core to a definition.
Now, it is true you could provision storage to containers from array-based storage and, to some extent, have it managed from the cluster. But that – sometimes called container-ready storage – contravenes the idea that everything should be managed from Kubernetes because no enterprise storage array is set-and-forget. It all requires management and provisioning at the array.
It may also contravene the principles of cloud-native in that workloads may not be very portable, although in theory you would need to ensure that the right type of media was available wherever containerised applications needed to run, even if strictly container-native, as defined here.
Can we boil all this down to questions that could be put to suppliers? Maybe. Here’s an attempt:
- Does your storage software run in containers?
- And does it virtualise, provision and run storage from there?
- What storage management is needed externally to Kubernetes?
Container-native storage suppliers
Here is a selection of suppliers that offer container-native storage:
