Add blog post introducing COSI (Object Storage) #35454
Conversation
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
|
/retitle Add blog post introducing COSI (Object Storage) Features don't really graduate to alpha - at least from an end user point of view, there's no earlier phase. Features come into being at some stability level (alpha, beta, stable) and we don't have a name for the state before the feature even exists. |
|
Hi from the Comms team! Just a reminder that the Ready to Review deadline for feature blogs is tomorrow, August 16. You will also be assigned a publication date. Is there anything we can do to help you right now? |
|
It is ready for review! |
|
@wlan0 Can you remove "placeholder" from the PR description? |
|
/assign |
@xing-yang I updated it |
| * Kubernetes Native - A completely kubernetes-API driven experience to provision, configure and manage buckets | ||
| * Self Service - A clear delineation between administration and operations (DevOps) to enable self-service capability for DevOps personnel | ||
| * Portability - Vendor Neutrality enabled through portability across Kubernetes Clusters and across Object Storage vendors* |
There was a problem hiding this comment.
There is no need to indent the list. Markdown is sensitive to indentations. Please avoid unnecessary indentations unless necessary.
The third item has a trailing star (*)?
There was a problem hiding this comment.
We are cautious about capitalization of words such as "Clusters", "Neutrality" etc, unless when we use them for a good reason.
There was a problem hiding this comment.
Thank you for the feedback - I've fixed the issues mentioned above and unindented all lists in the blogpost
|
@sftim what date should I set it to? |
|
@wlan0 Your scheduled publication date is 02 September! |
|
|
||
| ## Motivation | ||
|
|
||
| File and block storage are treated as first class citizens in the Kubernetes ecosystem via CSI. Workloads using CSI volumes enjoy the benefits of portability across vendors and across Kubernetes clusters without the need to change application manifests. An equivalent standard does not exist for Object storage. |
There was a problem hiding this comment.
Spell out CSI and add a hyper link to this blog https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/.
|
|
||
| * COSI Controller Manager | ||
| * COSI Sidecar | ||
| * COSI Driver |
There was a problem hiding this comment.
Add hyper link to each repo
There was a problem hiding this comment.
We usually don't link to code repos; it'd be better to link to reference docs.
(tip: once those docs exist, it's OK to go back to this article and add links to those docs).
There was a problem hiding this comment.
Sounds good, thanks for the suggestion. I'll update when the docs are in place
| In a nutshell, Bucket and BucketClaim can be considered to be similar to PersistentVolume and PersistentVolumeClaim respectively. The BucketClass’s counterpart in the file/block device world is StorageClass. | ||
|
|
||
| Since Object Storage is always authenticated, and over the network, access credentials are required to access buckets. The two APIs, namely, BucketAccess and BucketAccessClass are used to denote access credentials and policies for authentication. More info about these APIs can be found in the official COSI proposal - https://github.com/kubernetes/enhancements/pull/2813 | ||
|
|
There was a problem hiding this comment.
Use this link https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support rather than a PR link.
| Other than providing kubernetes-API driven bucket management, COSI also aims to empower DevOps personnel to provision and manage buckets on their own, without admin intervention. This, further enabling dev teams to realize faster turn-around times and faster time-to-market. | ||
|
|
||
| COSI achieves this by dividing bucket provisioning steps among two different stakeholders, namely the administrator (admin), and the operator (devops). The administrator will be responsible for setting broad policies and limits on how buckets are provisioned, and how access is obtained for them. The operator will be free to create and utilize buckets within the limits set by the admin. | ||
|
|
There was a problem hiding this comment.
Can you use "devops" instead of "operator" because "operator" has other meanings as well
There was a problem hiding this comment.
Our official term is “cluster operator”, BTW.
| Cross Provider portability is allowing organizations to move from one object storage provider to another seamlessly, and without requiring changes to application definitions (PodSpecs, StatefulSets, Deployment definitions etc.). This is only possible if the source and destination providers use the same data | ||
|
|
||
| _COSI does not handle data migration as it is outside of its scope. In case porting between providers requires data to be migrated as well, then other measures need to be taken to ensure data availability._ | ||
|
|
There was a problem hiding this comment.
It will be nice if you can add a "how to use COSI" section. See an example here: https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/#how-to-use-volume-snapshots
There was a problem hiding this comment.
The key thing to do with this PR is to update the publication date. I also added a bunch of inline feedback, and I do recommend having a read through that - there are a few places where the article doesn't follow our project-wide style guide for articles and tech docs.
| Other than providing kubernetes-API driven bucket management, COSI also aims to empower DevOps personnel to provision and manage buckets on their own, without admin intervention. This, further enabling dev teams to realize faster turn-around times and faster time-to-market. | ||
|
|
||
| COSI achieves this by dividing bucket provisioning steps among two different stakeholders, namely the administrator (admin), and the operator (devops). The administrator will be responsible for setting broad policies and limits on how buckets are provisioned, and how access is obtained for them. The operator will be free to create and utilize buckets within the limits set by the admin. | ||
|
|
There was a problem hiding this comment.
Our official term is “cluster operator”, BTW.
|
|
||
| This article introduces the Container Object Storage Interface (COSI), a standard for provisioning and consuming object storage in Kubernetes. It is a alpha feature in Kubernetes v1.25. | ||
|
|
||
| ## Motivation |
There was a problem hiding this comment.
| ## Motivation |
We don't start blog articles with a subheading.
|
|
||
| File and block storage are treated as first class citizens in the Kubernetes ecosystem via CSI. Workloads using CSI volumes enjoy the benefits of portability across vendors and across Kubernetes clusters without the need to change application manifests. An equivalent standard does not exist for Object storage. | ||
|
|
||
| Object storage has been rising in popularity in recent years as an alternative form of storage to filesystems and block devices. Object storage paradigm promotes disaggregation of compute and storage. This is done by making data available over the network, rather than locally. Disaggregated architectures allow compute workloads to be stateless, which consequently makes them easier to manage, scale and automate. |
There was a problem hiding this comment.
| Object storage has been rising in popularity in recent years as an alternative form of storage to filesystems and block devices. Object storage paradigm promotes disaggregation of compute and storage. This is done by making data available over the network, rather than locally. Disaggregated architectures allow compute workloads to be stateless, which consequently makes them easier to manage, scale and automate. | |
| Object storage has been rising in popularity in recent years as an alternative form of storage to filesystems and block devices. The object storage paradigm promotes disaggregation of compute and storage. This is done by making data available over the network, rather than locally. Disaggregated architectures allow compute workloads to be stateless, which consequently makes them easier to manage, scale and automate. |
There was a problem hiding this comment.
Consider hyperlinking to (eg) the Wikipedia entry on object storage.
|
|
||
| COSI aims to standardize consumption of object storage to provide the following benefits: | ||
|
|
||
| * Kubernetes Native - A completely kubernetes-API driven experience to provision, configure and manage buckets |
There was a problem hiding this comment.
| * Kubernetes Native - A completely kubernetes-API driven experience to provision, configure and manage buckets | |
| * Kubernetes Native - Use the Kubernetes API to provision, configure and manage buckets (sets of object storage) | |
| * ``` |
|
|
||
| COSI achieves this by dividing bucket provisioning steps among two different stakeholders, namely the administrator (admin), and the operator (devops). The administrator will be responsible for setting broad policies and limits on how buckets are provisioned, and how access is obtained for them. The operator will be free to create and utilize buckets within the limits set by the admin. | ||
|
|
||
| For example, an admin policy could be used to restrict maximum provisioned capacity to 100GB, and operators would be allowed to create buckets and store data upto that limit. Similarly for access credentials, admins would be able to restrict who can access which buckets, and operators would be able to access all the buckets available to them. |
There was a problem hiding this comment.
| For example, an admin policy could be used to restrict maximum provisioned capacity to 100GB, and operators would be allowed to create buckets and store data upto that limit. Similarly for access credentials, admins would be able to restrict who can access which buckets, and operators would be able to access all the buckets available to them. | |
| For example, a cluster operator could use an admin policy to restrict maximum provisioned capacity to 100GB, and storage managers would be allowed to create buckets and store data up to that limit. Similarly for access credentials, admins would be able to restrict who can access which buckets, and storage managers would be able to access all the buckets available to them. |
| * BucketAccess | ||
| * BucketAccessClass | ||
|
|
||
| In a nutshell, Bucket and BucketClaim can be considered to be similar to PersistentVolume and PersistentVolumeClaim respectively. The BucketClass’s counterpart in the file/block device world is StorageClass. |
There was a problem hiding this comment.
| In a nutshell, Bucket and BucketClaim can be considered to be similar to PersistentVolume and PersistentVolumeClaim respectively. The BucketClass’s counterpart in the file/block device world is StorageClass. | |
| In a nutshell, Bucket and BucketClaim can be considered to be similar to PersistentVolume and PersistentVolumeClaim respectively. The BucketClass's counterpart in the file/block device world is [StorageClass](/docs/concepts/storage/storage-classes/). |
| @@ -0,0 +1,91 @@ | |||
| --- | |||
| layout: blog | |||
| title: 'Introducing COSI: Object Storage Support in Kubernetes' | |||
There was a problem hiding this comment.
How about:
| title: 'Introducing COSI: Object Storage Support in Kubernetes' | |
| title: "Introducing COSI: Object Storage Management Using Kubernetes APIs" |
?
What do you think?
|
@sftim @xing-yang I've updated the PR based on your comments. Please review |
|
One nice-to-have fix would be to correct the date in the filename: |
|
/hold cancel |
|
/lgtm |
|
LGTM label has been added. Git tree hash: 4644cc217dbbdfed90d1d4a60164580ab004e052
|
|
@wlan0 , please rename the file so it corresponds with the publication date to |
|
@reylejano Updated! |
|
Changes since #35454 (comment) are fine. /lgtm |
|
LGTM label has been added. Git tree hash: 4243e404858fd85b7c20b3bfcc9650b55d190174
|
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sftim The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Blogpost introducing COSI (Container Object Storage Interface) in the v1.25 release of K8s.