Despite the initial assumptions that containers wouldn’t need persistent storage, common sense and consensus is moving towards the need to have some sort of continuity with containerised applications.  The reasons are pretty clear.  If a container hosting part of an application dies, it is easier to re-instantiate that container by using any existing data, rather than re-create or copy it from another location.  Persistence also makes auditors and other folks in enterprise environments just that little bit happier when policy and security can be applied to a more easily traceable asset.

The current model for persistent storage for containers is settling out on attaching volumes (LUNs) to a container and formatting that volume with a file system.  Through the container engine, the file system is exposed as a mount point within the container.  Storage could be taken from local disks (e.g. a volume created using an LVM) or from external storage presented to the container server/node.  The aim of the Container Storage Interface is to provide a common standard to connect container orchestration platforms (COs) like Kubernetes, Docker Swarm and Mesos to a plugin and ultimately to persistent storage.  Today each of these platforms handles external storage differently, which creates issues for vendors who have to write to multiple specifications.  Platforms such as Kubernetes, still require plugins to be shipped with mainline code, although that has started to change with the introduction of Flex volumes.

Figure 1 – Volume creation and mapping flow

Container Storage Interface

The CSI is a community-led effort to develop a standardised API for container orchestration platforms (COs) to talk to storage plugins.  Theoretically, with a standardised communication protocol, storage vendors will only need to write a plugin to a single specification.  CSI sets out the definition of how to talk to the plugin; exactly how the plugin is managed or operates is up to the storage provider.  CSI provides the following capabilities.

  • Dynamic provisioning and decommissioning of volumes.
  • Attachment and detachment of volumes from a host node.
  • Mounting and unmounting of a volume from a host node.

Figure 1 shows the potential lifecycle of a new volume request.  The CreateVolume/DeleteVolume calls are used to (quite obviously) create and delete a volume on the storage platform.  Once a volume is created, ControllerPublishVolume/ControllerUnpublishVolume ensure that an existing volume is made physically available to a container node/host.  Finally, NodePublishVolume/NodeUnpublishVolume is used to associate a volume with a specific container.  For pre-provisioned (existing) volumes, the plugin simply maps and publishes volumes to a host.

Architecture

CSI is divided up into a number of architectural designs that determine how plugins are deployed.  The architectures match typical CO implementations that have master and node hosts.  The three scenarios are:

  • Master/Node with separate plugins for both controller and node functions.
  • “Headless” where the plugins still run separately for controller and node but only run on the node hosts.
  • Headless combined, where a single plugin provides the controller and node capabilities together.

Within each plugin there are three services that process RPC calls:

  • Identity service – implemented by both the controller and node plugins.  This exposes two functions or gRPC calls.
  • Controller service – run on controller plugins.  This exposes nine functions.
  • Node service – implemented by the node plugin and exposes five functions.

Details of each function call can be found at the Github specification page for CSI. Dell EMC has developed a set of tools called GoCSI to help with plugin testing.  Details can be found here.

The Architect’s View

Currently, only Mesosphere (DC/OS) and Kubernetes are supporting CSI, with other vendors expected to follow (including Cloud Foundry).  At the time of writing it wasn’t clear if Docker had any involvement in the project or was going alone with their existing plugin offerings.  However, the real push needs to come from the storage industry in supporting features and functionality for working with storage platforms.  In particular, although the current CSI standard doesn’t specifically describe security and credentials mapping, it would be beneficial to have this more rigorously defined.

In any event, block storage isn’t a long-term solution for container storage, unless we accept that data mobility is going to be delivered at the application layer.  This may have been the original vision with containers, but in the long run, I expect that enterprises will want a bit more security with their information.

Further Reading

Comments are always welcome; please read our Comments Policy.  If you have any related links of interest, please feel free to add them as a comment for consideration.  

Copyright (c) 2007-2018 – Post #3CAD – Chris M Evans, first published on https://blog.architecting.it, do not reproduce without permission. Photo credit iStock. 

Written by Chris Evans

With 30+ years in IT, Chris has worked on everything from mainframe to open platforms, Windows and more. During that time, he has focused on storage, developed software and even co-founded a music company in the late 1990s. These days it's all about analysis, advice and consultancy.