Introducing Container Storage Interface (CSI) Alpha for Kubernetes

--- title: " Introducing Container Storage Interface (CSI) Alpha for Kubernetes " date: 2018-01-10 slug: introducing-container-storage-interface url: /blog/2018/01/Introducing-Container-Storage-Interface --- One of the key differentiators for Kubernetes has been a powerful [volume plugin system](/docs/concepts/storage/volumes/) that enables many different types of storage systems to: 1. Automatically create storage when required. 2. Make storage available to containers wherever they’re scheduled. 3. Automatically delete the storage when no longer needed. Adding support for new storage systems to Kubernetes, however, has been challenging. Kubernetes 1.9 introduces an [alpha implementation of the Container Storage Interface (CSI)](https://github.com/kubernetes/features/issues/178) which makes installing new volume plugins as easy as deploying a pod. It also enables third-party storage providers to develop solutions without the need to add to the core Kubernetes codebase. Because the feature is alpha in 1.9, it must be explicitly enabled. Alpha features are not recommended for production usage, but are a good indication of the direction the project is headed (in this case, towards a more extensible and standards based Kubernetes storage ecosystem). ### Why Kubernetes CSI? Kubernetes volume plugins are currently “in-tree”, meaning they’re linked, compiled, built, and shipped with the core kubernetes binaries. Adding support for a new storage system to Kubernetes (a volume plugin) requires checking code into the core Kubernetes repository. But aligning with the Kubernetes release process is painful for many plugin developers. The existing [Flex Volume plugin](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) attempted to address this pain by exposing an exec based API for external volume plugins. Although it enables third party storage vendors to write drivers out-of-tree, in order to deploy the third party driver files it requires access to the root filesystem of node and master machines. In addition to being difficult to deploy, Flex did not address the pain of plugin dependencies: Volume plugins tend to have many external requirements (on mount and filesystem tools, for example). These dependencies are assumed to be available on the underlying host OS which is often not the case (and installing them requires access to the root filesystem of node machine). CSI addresses all of these issues by enabling storage plugins to be developed out-of-tree, containerized, deployed via standard Kubernetes primitives, and consumed through the Kubernetes storage primitives users know and love (PersistentVolumeClaims, PersistentVolumes, StorageClasses). ### What is CSI? The goal of CSI is to establish a standardized mechanism for Container Orchestration Systems (COs) to expose arbitrary storage systems to their containerized workloads. The CSI specification emerged from cooperation between community members from various Container Orchestration Systems (COs)--including Kubernetes, Mesos, Docker, and Cloud Foundry. The specification is developed, independent of Kubernetes, and maintained at [https://github.com/container-storage-interface/spec/blob/master/spec.md](https://github.com/container-storage-interface/spec/blob/master/spec.md). Kubernetes v1.9 exposes an alpha implementation of the CSI specification enabling CSI compatible volume drivers to be deployed on Kubernetes and consumed by Kubernetes workloads. ### How do I deploy a CSI driver on a Kubernetes Cluster? CSI plugin authors will provide their own instructions for deploying their plugin on Kubernetes. ### How do I use a CSI Volume? Assuming a CSI storage plugin is already deployed on your cluster, you can use it through the familiar Kubernetes storage primitives: PersistentVolumeClaims, PersistentVolumes, and StorageClasses. CSI is an alpha feature in Kubernetes v1.9. To enable it, set the following flags:

Kubernetes 1.9 introduces an alpha implementation of the Container Storage Interface (CSI), designed to simplify the process of adding new storage systems to Kubernetes. CSI enables third-party storage providers to develop solutions independently of the core Kubernetes codebase, addressing challenges associated with in-tree volume plugins and the Flex Volume plugin. CSI allows storage plugins to be developed out-of-tree, containerized, deployed via standard Kubernetes primitives, and consumed through familiar Kubernetes storage primitives. The goal of CSI is to establish a standardized mechanism for Container Orchestration Systems to expose arbitrary storage systems to their containerized workloads.