Cloud Native / Containers / Storage

What the Container Storage Interface Means for Storage Evolution

9 May 2019 5:00pm, by

A blog post by Saad Ali, senior software engineer at Google, drew considerable attention early year when Ali first described Kubernetes GA in “Container Storage Interface (CSI) for Kubernetes GA.” In that post, Ali described how “CSI was developed as a standard for exposing arbitrary block and file storage systems to containerized workloads on Container Orchestration Systems (COs) like Kubernetes.” Among other things, CSI protects backwards compatibility with protection by a Kubernetes deprecation policy, Ali wrote.

The implications of CSI, as well as Kubernetes storage and the evolution of containers, were the subject of a podcast episode of The New Stack Analyst hosted by Alex Williams, founder and editor-in-chief of The New Stack, with Janakiram MSV, a TNS correspondent and principal of Janakiram & Associates. Joining Ali as a guest was Anand Babu Periasamy, co-founder and CEO at MinIO. The podcast was recorded during DockerCon 2019, Docker’s flagship user conference, which recently took place in San Francisco.

CSI was designed to help remove many of the interface issues users faces. “It became clear that everybody in the industry would benefit from a collaboration of coming up with a standard for blocking file storage and so that’s where this project, the container storage interface project, was born,” Ali said. “It’s a collaboration amongst different orchestration systems including Kubernetes, Mesos, Cloud Foundry and Docker with the purpose of being able to integrate an orchestration system with a blocker file storage system.”

“One of the goals was to create a ‘generally usable’ interface, but we also didn’t want it to be the lowest common denominator,” Ali said. “We realized that different storage systems have their own strengths and their own functionality and we didn’t want to kind of be in the way of them being able to expose that,” Ali said.

“And so, the interface itself stays in the control plane but it also allows for the ability to pass through opaque parameters to be able to tune that storage system so that cluster administrators can tune specific storage systems as needed for their environments.”

The state versus statelessness aspect of containers and storage, also represents a critical component in cloud native. “Very few people understand that ‘state’ always exists,” Periasamy said. “With stateless applications and microservices, it is that that the state is no longer with the applications since it is elsewhere.”

There are thus different kinds of storage systems, databases, etc. — as well as stateful containers, Periasamy said. “The idea is that if you reduce the state footprint of your infrastructure, then the bulk of your applications that become stateless can behave cloud natively, meaning they become more resilient… and they can now be abstracted,” Periasamy said. “That is [where the CSI interfaces that come in between] actually makes the storage subsystems, the stateful ones, appear as a service and the goal is to reduce the state footprint of your infrastructure….So, once you go cloud native, there are numerous advantages.”

In this Edition:

2:01: Why CSI.
6:34: Compare and contrast the workflow in bringing a third-party storage engine to Kubernetes with volume plugins versus CSI.
12:57: The physical management of the storage affinity.
16:42: State and statelessness to application architectures.
19:50: Top scenarios and use cases where this is becoming an intrinsic deployment to a workload.
27:38: The current direction of workloads on these architectures, and how you see CSI evolving.

Feature image via Pixabay.

A newsletter digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.