Introducing COSI by Kubernetes API
Although it is not the only platform for containers, Kubernetes has emerged as the industry norm for orchestration. Today’s application development requires Kubernetes because it enables businesses to create and deploy cloud-native applications regardless of the underlying infrastructure and environment. However, Kubernetes does have some limitations.
Fortunately, new developments have made it possible to develop scalable, and portable application architectures.
As a substitute for file systems and block devices in terms of storage, object storage has grown in popularity recently. The segmentation of computation and storage is encouraged by the object storage paradigm. To achieve this data is made available through the network rather than locally. You can create stateless workloads using the granular architecture, which makes them simpler to manage, scale and automate.
According to Kubernetes Consulting Companies, up until recently, block and file storage was the sole type of persistent storage handled by Kubernetes. However, the Container Object Storage Interface (COSI), which was developed by the Kubernetes community, is a fascinating new standard.
Without altering the Kubernetes source, storage providers can install object storage solutions thanks to COSI. Additionally, Kubernetes enables native object storage, resource consumption, and management for application developers.
Find out how the new COSI standard design makes systems more practical and usable with Kubernetes persistent storage, elaborated by one of the leading Kubernetes Consulting Services, Urolime.
COSI – An Alpha feature in Kubernetes v1.25
COSI seeks to standardize object storage usage to offer the following advantages:
- Kubernetes Native: Uses the Kubernetes API to deploy, configure, and manage buckets.
- Self-service: The ability of DevOps professionals to self-serve is enabled by a distinct division between management and operations.
- Portability – The flexibility to move between Kubernetes clusters and object storage vendors is supported by vendor neutrality.
Only when both providers implement the same datapath-API is portability between them conceivable. You can move from AWS S3 to Ceph or from AWS S3 to MiniIO and vice versa because everyone uses the S3 API. Migrations between Google Cloud and AWS S3 are not possible.
Architecture
There are three components to COSI architecture:
- COSI Controller Manager: The COSI Controller Manager acts as the primary controller for overseeing COSI API object updates is the COSI Controller Manager. It takes care of the conditions for setting up, deleting, and controlling access to your repository. Each Kubernetes cluster needs one instance of Controller Manager. You only require one object storage provider, even if your cluster makes use of more than one.
- COSI Sidecar: Between COSI API requests and vendor-specific COSI drivers, the COSI Sidecar serves as a mediator. This component uses the standard gRPC protocol that vendor drivers must follow.
- COSI Driver: To establish buckets, control bucket access, and manage bucket lifecycles, a vendor-specific component known as a COSI Driver must receive sidecar requests and make the necessary vendor API calls.
API
The COSI API focuses on compartments since they are a consistent abstraction for storing items. The three administration APIs for Kubernetes are defined by COSI as follows:
- Bucket
- BucketClass
- BucketClaim
PersistentVolume and PersistentVolumeClaim can be compared to Bucket and BucketClaim, respectively. In the domain of file/block devices, StorageClass and BucketClass are interchangeable terms.
Access to the bucket requires credentials since object storage is always authenticated to the network. Credentials and authentication guidelines are presented using two APIs, BucketAccess and BucketAccessClass.
Two more APIs are created to control bucket access:
- BucketAccess
- BucketAccessClass
Self-Service
Along with offering Kubernetes API-based bucket management, COSI gives DevOps experts the autonomy to provision and control their buckets without help from administrators. The development team gains from a shorter turnaround resulting in faster delivery.
COSI accomplishes this by assigning the administrator and the cluster operator to each stakeholder during the bucket provisioning step. Administrators should create broad guidelines and limitations on how segments are used, deployed, and accessed. Within the parameters set by the administrator, cluster operators can create and use compartments.
For instance, a developer may construct buckets and store data up to the 100 GB maximum available capacity set by a cluster operator using a management policy. Developers have access to every accessible compartment, whereas credential administrators can limit who has access to particular compartments.
Portability
The third objective of COSI is to establish vendor neutrality bucket handling. COSI permits two different kinds of portability.
Cross-provider portability aims to make it simple for teams or organizations to switch from one object storage provider to another without modifying their application definitions. This is feasible only when the source and the destination providers utilize the same data.
Conclusion
With Container Object Storage Interface (COSI), Kubernetes cluster users and administrators will have a standardized and recognizable method for managing object storage. Without ever touching the core Kubernetes code, third-party storage providers can use the Container Object Storage Interface to create and deploy plugins that expose new object storage systems in Kubernetes.
