jcpjr - Fotolia

Container-native storage: A definition, and what to ask suppliers

We look at container-native storage – aka cloud-native storage – what defines it, and its benefits as a way of bringing persistent Kubernetes storage to containerised applications

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.

Read more on container storage

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:

Next Steps

Five essential steps to build a cloud-native strategy

Highlights from KubeCon + CloudNativeCon Europe 2022

Read more on Virtualisation software

CIO
Security
Networking
Data Center
Data Management
Close