 What's next after CSI? An introduction to object storage for Kubernetes and moving beyond file and block storage Hello, everyone. My name is Chris, and I'm a software engineer at Red Hat So today we're going to be discussing a few main topics starting off with a brief introduction to object storage Then an overview of CSI and Kubernetes followed by the need for cozy and the cozy architecture So what is object storage? In object storage data is broken up into small discreet units known as objects which are then Stored in a flat architecture Data can be accessed through simple network APIs and we organize these objects into Logical containers commonly known as buckets This is an extremely cost-efficient and scalable way to storage large quantities of data while maintaining quick access And so what's the use case as I mentioned it is a network focused software defined storage design And so this makes it very flexible and so object storage is well suited for static data always connected mobile devices deep learning and analysis We can enforce more granular permissions on these buckets through bucket policies and namespacing However, one challenge is that there's no definitive protocol for consumption and creation of objects or buckets And so what's the role of CSI? Well CSI Provides a platform to expose block and file storage systems prior to CSI connecting to new volume plugins Was a core part of Kubernetes But CSI allowed vendors to move this logic into separate drivers And so some popular CSI drivers today expose Amazon EBS, Ceph or Google Cloud Store And so this meant more options for storage and it made core Kubernetes more secure and reliable So what are the core concepts in CSI? Well, first there's the storage class, which is how Kubernetes admins define different classes of storage This is followed by persistent volumes, which are pieces of storage that are provisioned statically by an admin or dynamically through a storage class Lastly we have persistent volumes Which are requests for access to storage by a user and so PVCs consume PV resources and they specify the size and access mode So where does cozy fit in so in cozy's there's six main terms that are used There's the bucket class the bucket request the bucket the bucket access class the bucket access and the bucket access request And so we can draw some comparisons between cozy and CSI Where cozy has a bucket class CSI defines a storage class a bucket is very similar to a Persistent volume and a bucket request and bucket access requests together Kind of mimic a persistent volume claim And so cozy emphasizes the granularity of bucket access policies through bucket access classes Bucket accesses and bucket access requests CSI on the other hand has less granular access policies And instead allows for predefined access modes of read write ones read only many and read write many So The architecture of cozy Essentially has four main components. There's the cozy central controller the cozy sidecar controller The cozy node adapter and lastly the vendor provisioner And so the vendor provisioner Communicates with the sidecar through gRPC and the sidecar is Kubernetes aware and So on the right you can see the relationship between some of the different objects So a bucket request references the bucket class and a bucket access request references a bucket access class So here's an example of a sample workflow a simple workflow for creating a bucket So first things first the admin would define Bucket class this would be followed by the user creating a bucket request at some later time The central controller would notice the bucket request and it would create a bucket resource The sidecar upon noticing the bucket will call the create bucket gRPC call And the vendor provisioner in turn will create the backing bucket And so although not pictured the node adapter would be responsible for the final step of mounting the secret onto the pod So that's all for this presentation. Thank you for your time If you want to get involved with the cozy project check out the sick storage cozy slack channel In the Kubernetes slack or join the weekly meetings on Thursdays at 6 p.m. GMT. Thank you