Storage
Mobility
Protection
Analysis and control
TOPICShare
What Is Container Storage Interface (CSI)?
The Container Storage Interface (CSI) is an initiative supported by the Cloud Native Computing Foundation (CNCF). It was created during the early days of containerization technology, for the purpose of standardizing the use of container persistent storage. CSI was intended to address the challenge of fragmented container storage technology, using different storage technologies and methods.
CSI is a standard that specifies how a storage system should expose data to container orchestrators, and how an orchestration platform should connect to storage equipment. CSI-compliant storage systems and container orchestrator platforms can use CSI processes to integrate with each other. There are currently over a hundred CSI-compatible storage solutions that can integrate well with container orchestration platforms, of which the most popular is Kubernetes. Thus CSI is the foundation of flexible, manageable Kubernetes storage.
In this article:
- Why Is CSI Important?
- Container Storage Interface (CSI): Interface and Architecture
- How Does CSI Benefit Kubernetes Users?
- Kubernetes Storage with Cloud Volumes ONTAP
Why Is CSI Important?
Before the Container Storage Interface (CSI), each orchestration solution had its own plug-ins for different storage volumes. This resulted in a number of disadvantages, including:
- Implementation of new volume plug-ins required significant effort
- Storage providers relied on the core code implementation and release policy of the specific orchestration solution
- The solution’s developers had to test the volume plug-ins
- Errors could affect various components of an orchestration solution
Today, CSI allows third-party storage providers to build and deploy storage plug-ins without having to rely on the core code of an orchestration solution. This also offers more flexibility for the orchestration solution to use external storage, reducing the effort required of the storage provider. CSI makes these systems safer and more reliable.
There are several advantages to using CSI for handling container orchestration solutions (and external storage). These include:
- Reduced effort involved in implementing new volume plug-ins
- No dependence on the orchestration solution’s code base or its release policy
- Orchestration solution developers only have to test the implementation of the interface, not of each storage plug-in
- The core of the solution is decoupled from the storage volumes, making the system more stable and secure overall
- Storage solution developers can produce their solutions more independently
Container Storage Interface (CSI): Interface and Architecture
The Container Storage Interface is a community-based project for developing a standardized API enabling communication between container orchestration (CO) platforms and storage plugins. In theory, a standardized communication protocol allows storage providers to write plugins more easily, to just one specification. CSI defines how the CO talks to a plugin but the exact form in which the plugin operates (or is managed) is determined by the storage vendor.
Capabilities of CSI include:
- Volumes can be provisioned and decommissioned dynamically
- Volumes can be attached and detached from host nodes
- Volumes can be mounted and unmounted from host nodes
Volumes are created on the storage platform via CreateVolume and DeleteVolume calls. The new volumes are then made available to container nodes or hosts via the ControllerPublishVolume and ControllerUnpublishVolume calls. Volumes can be associated with specific containers using NodePublishVolume and NodeUnpublishVolume. To publish existing (or pre-provisioned) volumes, the plugin just has to map them to a host.
CSI has three architectures that define how plugins are deployed. Each architecture matches typical container orchestration implementations with node and master hosts:
- A master/node model—with different plugins for the controller and node capabilities
- A headless model—the plugins only run on node hosts, but they run separately for the controller and node functions
- Combined headless—a single plugin provides both controller and node functions
Each plugin contains three services to process remote procedure calls (RPCs):
- Identity—exposes two gRPC functions, being implemented by both the node and controller plugins
- Controller—exposes nine functions, runs on a controller plugin
- Node—exposes five functions, being implemented by the node plugin
How Does CSI Benefit Kubernetes Users?
The Container Storage Interface enables the use of various storage devices for Kubernetes—Kubernetes can work with any device that has a CSI driver. Administrators can leverage CSI drivers for both Kubernetes and other CO systems, although CSI is primarily used for storage abstraction in Kubernetes, based on storage classes and persistent volumes and claims.
Related content: learn more in our guide to Kubernetes Persistent Volumes
Before the interface was made generally available (in version 1.13), Kubernetes used in-tree plugins to expose storage. These plugins were directly integrated into Kubernetes’ binaries, and while they were effective, they also posed three main challenges:
- To make their storage products compatible with Kubernetes, vendors had to work with multiple layers of bureaucracy to ensure the plugin could be integrated with the Kubernetes software.
- It was difficult for vendors to upgrade or fix bugs in the plugins, because they were part of the core code of Kubernetes.
- If a plugin was poorly written, it could destabilize the entire Kubernetes platform.
Today, CSI drivers have replaced the traditional plugin system, as they offer more stability and reliability in Kubernetes—this is because they reside outside of Kubernetes’ core code. However, the main benefit of CSI is its simplicity. Vendors can now create a CSI driver, using an API, to allow hardware products to work with Kubernetes. They no longer have to try and receive Kubernetes integration support as they did with the plugins—they can create drivers (or new versions of drivers) whenever they choose.
Learn more about Kubernetes CSI Volumes and How to Build a CSI Driver here.
Kubernetes Storage with Cloud Volumes ONTAP
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP capacity can scale into the petabytes, and it supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
In particular, Cloud Volumes ONTAP supports Kubernetes Dynamic Provisioning with Cloud Volumes ONTAP and Astra Trident CSI driver.
Learn more about how Cloud Volumes ONTAP helps to address the challenges of containerized applications in these Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.
