Mar 30, 2017
Benjamin Hindman
D2iQ
4 min read
Standard interfaces can provide many benefits. For technology vendors, they facilitate collaboration, enable interoperability, and save time and resources from building one-off integrations. For customers, standard interfaces accelerate technology adoption, simplify the user experience, and enable choice. The success of the Container Networking Interface got us to think: can we do the same for container storage?
Current Challenges for Container Storage
With no standard framework or interface, each of the leading container orchestration solutions — Cloud Foundry, DC/OS (Mesos), Docker, and Kubernetes — currently have their own way of handling storage. Docker has DVDI; Kubernetes has Flex volume; and DC/OS supports local volume, DVDI, and REX-Ray. These implementations have different design criteria, incompatible APIs, and implementations with various degrees of quality and reliability. From the storage vendor side, the story looks even more grim. Vendors are forced to prioritize development for one platform over another and embrace a non-trivial testing matrix. The result is a fragmented container storage ecosystem and a rough experience for end users. We as a community can do better.
Collaborating on a Solution
As we started integrating more storage solutions into Apache Mesos and DC/OS, it became clear that we could make this better. So in the fall of 2016, we started a discussion with Craig Mcluckie (at the time a Kubernetes PM at Google) and Sam Ramji (at the time CEO of the Cloud Foundry Foundation). We acknowledged that CNI had been successful for container networking and wondered if we could do the same for container storage.
Our friends at {code} by Dell EMC had been working on a project they called libstorage and they were the first vendor we started collaborating and validating our ideas with. Great discussions with Portworx and Diamanti followed. Diamanti was leading Flex Volumes 2, an iteration on Kubernetes storage interface. With the confidence gained from these discussions we invited product and engineering representatives from Cloud Foundry, Docker, and Kubernetes to join us to brainstorm what a container storage interface might look like. Jie Yu from Mesosphere and Saad Ali from Google were tasked with building the first draft of that interface, called the Container Storage Interface (CSI).
In early 2017 {code} by Dell EMC presented libstorage to the CNCF Technical Oversight Committee (TOC) and the feedback was very clear that we needed to form a dedicated CNCF working group around storage, called wg-storage. That working group is just now getting started and we're looking forward to working with a broader audience and more storage providers to help make CSI successful.
Introduction to Container Storage Interface (CSI)
CSI's ultimate goal is to have storage vendors write one plugin that works with all container orchestration platforms. CSI will provide a common set of APIs for all interactions between the storage vendors and the container orchestration platforms. Each storage vendor is responsible for implementing a CSI compatible plugin for their storage solution. Container orchestration platforms will then use the CSI APIs and the vendor-created plugins to interact with the storage provider during the lifecycle of the container storage. 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.
CSI on Apache Mesos and Mesosphere's DC/OS
Our teams have already started designing the integration of CSI into Mesos and DC/OS (you can see the Mesos design doc to integrate CSI and follow the work on Apache.org here and here). Our immediate goal is to make provisioning and managing storage on DC/OS as simple as running a container — and CSI will be the foundation for that. But CSI is just one part of our bigger vision of not only integrating storage into containers but also building and scaling storage solutions on top of Mesos and DC/OS. The distributed systems that make up our storage systems are complex and should be able to benefit from the same container orchestration primitives that make running stateless applications easier. We want to enable storage vendors to provide Storage-as-a-Service on top of DC/OS to make it easy to manage and scale storage solutions in the same way they can easily manage and scale their containers.
We would like to recognize the many individuals who have supported and contributed to this emerging interface, with special thanks to Mike Goelzer and Brian Goff from Docker; Julian Hjortshoj from Pivotal Cloud Foundry; Saad Ali, Tim Hockin and Michael Rubin from Google; Clinton Kitson from Dell/EMC; Gou Rao from Portworx; and Gopal Sharma and Chakravarthy Nelluri from Diamanti.
We are excited for the road ahead of us for containers and storage. Stay tuned for more updates and information!
Ben Hindman, Jie Yu, James DeFelice
