Kubernetes CSI and COSI: a Symbiotic Relationship

Sidhartha Mani -

The push to standardize Object Storage in Kubernetes has gained significant momentum in the recent months. The new standard, named COSI for Container Object Storage Interface, strikes a similar chord to CSI  —  a well known standard for consuming storage in Kubernetes.

In this article, I’ll dive into COSI, its architecture, and how it fits alongside CSI. Finally, I’ll introduce one of MinIO’s own CSI drivers  —  DirectCSI.

Container Object Storage Interface

COSI is a set of APIs that automates provisioning and management of object storage buckets in Kubernetes. In addition to automation, COSI also promises:

  • Vendor Independence
  • Cross cluster portability

In essence, consumers of COSI would be able to utilize object storage for their workloads in an automated, vendor agnostic manner, while retaining the ability to shift their workloads to a different platform/object storage vendor without any changes to their workload definitions*.

Users would be able to specify the need for a bucket in their PodSpec (the workload specification), and COSI would kick-in to create the Bucket in the backend, generate credentials for accessing it, and provide the bucket and its access credentials to the Pod that requested it. COSI also automates the tear-down and revocation of access one the workload is done using the bucket.

In order to achieve this, COSI integrates with object storage vendors using a standardized gRPC API that allows any object storage vendor to become COSI compatible.

Architecture

Here is a diagram depicting the key integration points of COSI and where it fits in the cloud-native landscape:

CSI

CSI is a set of APIs that automates the provisioning and management of block devices and filesystem. That is the fundamental difference between COSI and CSI.

In a Kubernetes cluster, where both block storage and object storage are needed — both COSI and CSI drivers can be run simultaneously. In fact, MinIO deployments follow this very same architecture, where object storage is provided by MinIO, while the drives for MinIO server itself is provided by a CSI driver.

DirectCSI

MinIO purpose-built its own CSI driver called DirectCSI.

DirectCSI provisions and manages block devices for containerized workloads running in Kubernetes. The key differentiator for DirectCSI, compared to the vast majority of CSI drivers out there, is that it provides workloads with direct access to local drives — as the name implies.

Direct access is needed for high-performance applications like MinIO. As MinIO manages the durability, availability, and encryption of data on its own, a CSI layer that provisions remote drives (in contrast to local drives) would only act as a performance bottleneck.

MinIO like storage applications do not benefit from any of the value traditionally obtained by using remote drives — data durability, encryption at rest, availability etc.

DirectCSI manages the complexity of scheduling workloads on nodes where free space is available to ensure that workloads only utilize drives local to the node on which they are running.

Try out DirectCSI today, visit https://github.com/minio/direct-csi to get started!

*COSI does not automate data transfer from one bucket to another.