To understand ‘Why Container Storage Interface’, let’s start with some history. Back in 2015, we noticed gaps in integrating storage with Container Orchestrators (CO’s) – there was a lack of interoperability with containers and persistent storage as well as a collaborative community (they noticed it too…). This led the {code} team to take on projects for storage interoperability. Two are applicable to my story: REX-Ray and libStorage.

Then in 2016, we started conversations with Cloud Native Computing Foundation (CNCF) on contributing REX-Ray and libStorage to the Foundation to expand cloud native computing environments to include storage (and what environment does not need storage – but that is a topic for other blogs)”. At this point there were a few key things that happened. 1) The CNCF Technical Oversight Committee (TOC) decided to create a sub-committee called the storage working group to further discuss what storage means in cloud native; 2) the TOC decided to embrace a strategy for similar interoperability projects for networking resulting in the adoption of Container Network Interface (CNI); and 3) the CO’s got on board.




The dialog included Mesos, Kubernetes, Docker, and Cloud Foundry who decided to work together. They saw the need for containers and storage to talk to one another to increase interoperability and simplify the user experience. Boom! The Container Storage Interface (CSI) project was born – March 2017.

Since its formation the CO’s, along with input from storage vendors and community members, have made progress in developing a CSI spec and some are working on design documents and implementations. So what’s next – well, I’ll do some explaining – so keep reading.


What is the Container Storage Interface?

The Container Storage Interface (CSI) is a universal storage interface (effectively an API) between container orchestrators and storage providers that will allow easy interoperability between the two. Container orchestrators who adopt CSI can basically leverage any storage provider, cloud or otherwise. Likewise, CSI enables the storage providers to provide storage services to any container orchestrator that implements the specification.

CSI adoption will provide applications with portability across infrastructures. For the user, this means that one can count on a consistent runtime experience regardless of which container orchestrator or storage provider is used.


Who are the players?

Or, as we like to say, who’s who in the zoo?

All of the Container Orchestrators: Mesosphere for Mesos, Google for Kubernetes, Docker and Pivotal for Cloud Foundry, are involved.

Companies and projects with an interest in storage are heavily involved. The {code} team is actively participating in the CSI project to provide early implementations and feedback on the storage interface.

Cloud Native Computing Foundation (CNCF): They are the a non-profit foundation helping build and sustain cloud native environments. We work closely with them because (1) we are Platinum sponsor and (2) we would ultimately like CSI to be a CNCF project.

CNCF Technical Oversight Committee: This committee is run independently by the community and member projects to decide what projects to bring into CNCF. How this relates to CSI – this committee will decide what, if any, CSI projects will become CNCF projects.

CNCF TOC Storage Working Group (SWG): This is a Storage working group that is a sub-group of the TOC committee. They review storage, its importance to cloud native, and make recommendations for TOC decisions about projects. They are in the zoo because they are responsible for storage.


Why does this matter?

It’s about the technology and how it will impact the container orchestrators and the storage vendors.

When the container orchestrators support CSI, they should become more applicable to a broader range of applications, thus increasing container adoption. By developing and supporting a consistent standard, it is more likely that the storage providers will add support for this capability. The more storage providers that support CSI, the faster customers will be able to adopt container technology for a broader range of applications.

From a storage vendor perspective, they have only one plugin to write that will work with all container orchestration (CO) platforms. CSI will provide a common set of APIs for the interactions between the storage and the CO, and the storage vendor will be responsible for implementing a CSI compatible plugin for their storage solution.

CSI’s goal is to support the most common use cases for container storage, volume storage devices, and raw block devices with local and external storage.

For the user, this is facilitating container adoptions and storage is a functionality that is needed. This gives users true portability without having to worry about specific implementations of the infrastructure underneath. While it’s fun to do a “hello world” in a container, in reality if you run any applications in a container, it requires storage of some kind. Applications that do anything require storage.


What’s next:

A GitHub Spec was created in Q1 CY2017. Container Orchestrators are in the process of creating design documents.

We will communicate information on CSI as it becomes available (via our Newsletter and Twitter). You can also keep up with the activities via these resources:

Google Group: Container Storage Interface Community

GitHub: Container Storage Interface

CSI Spec:


Other Reading:

Ben Hindman’s blog: CSI: Towards a more universal storage interface for containers

Clint Kitson’s blogs: Understanding storage in a cloud native context and Toward a new contract with infrastructure

Steve Wong: Kubernetes 1.7 offers enhanced support for stateful workloads

And Steve’s follow on: Revisiting the 12 factors, 6 years later

Kenny Coleman: Container Storage Architectures: How Does Kubernetes, Docker, and Mesos Compare?