We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

COSI : a brief update

Formal Metadata

Title
COSI : a brief update
Title of Series
Number of Parts
287
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
For applications in Kubernetes, CSI provides a way to consume file/block storage for their workloads. The main motivation behind the Container Object Storage Interface is to provide a similar experience for Object Store. Basic idea is to provide a generic, dynamic provisioning API to consume the object store and the app pods can access the bucket in the underlying object-store like a PVC. The major challenge for this implementation there is no standard protocol defined for object and the COSI project need to be vendor agonistic. For example, in the case of RGW, the application can request for S3 bucket and Swift bucket from the same ceph-cosi driver. Ideally, the Kubernetes resource for the bucket can be migrated to the different cloud if the drivers support it and the application can seamlessly continue with the same k8s object. It won't handle the orchestration/management of object store, rather it will be another client and provide bucket access on behalf of applications running in Kubernetes. A similar session was given in last FOSDEM'21, but the whole project went through design changes and will share that information.