首页 运维杂谈​COSI:对象存储也可以通过 K8S API 管理了!

​COSI:对象存储也可以通过 K8S API 管理了!

运维派隶属马哥教育旗下专业运维社区,是国内成立最早的IT运维技术社区,欢迎关注公众号:yunweipai
领取学习更多免费Linux云计算、Python、Docker、K8s教程关注公众号:马哥linux运维

​COSI:对象存储也可以通过 K8S API 管理了!

本文介绍了容器对象存储接口 (COSI),它是在 Kubernetes 中供应和使用对象存储的标准。它是 Kubernetes v1.25 中的一个 alpha 功能。

文件和块存储通过容器存储接口 CSI 在 Kubernetes 生态系统中被视为一等公民。使用 CSI 卷的工作负载可以享受跨供应商和跨 Kubernetes 集群的可移植性优势,而无需更改应用程序清单。对象存储不存在等效标准。

近年来,对象存储作为文件系统和块设备的替代存储形式越来越受欢迎。对象存储范式促进了计算和存储的分解。这是通过网络而不是本地提供数据来完成的。分解架构允许计算工作负载是无状态的,从而使它们更易于管理、扩展和自动化。

COSI

COSI 旨在标准化对象存储的使用,以提供以下好处:

  • Kubernetes Native:使用 Kubernetes API 来配置、配置和管理存储桶
  • 自助服务:管理和运营 (DevOps) 之间的明确划分,为 DevOps 人员启用自助服务能力
  • 可移植性:通过跨 Kubernetes 集群和跨对象存储供应商的可移植性实现供应商中立性

跨供应商的可移植性只有在两家供应商都支持通用数据路径 API 时才有可能。例如。可以从 AWS S3 移植到 Ceph,或从 AWS S3 移植到 MinIO,反之亦然,因为它们都使用 S3 API。相反,无法从 AWS S3 和 Google Cloud 的 GCS 移植,反之亦然。

Architecture

COSI 由三个部分组成:

  • COSI Controller Manager
  • COSI Sidecar
  • COSI Driver

COSI Controller Manager 充当处理 COSI API 对象更改的主控制器。它负责处理存储桶创建、更新、删除和访问管理的请求。每个 Kubernetes 集群都需要一个控制器管理器实例。即使集群中使用了多个对象存储提供程序,也只需要一个。

COSI Sidecar 充当 COSI API 请求和供应商特定 COSI 驱动程序之间的转换器。该组件使用供应商驱动程序应满足的标准化 gRPC 协议。

COSI Driver 是供应商特定组件,它接收来自 sidecar 的请求并调用适当的供应商 API 以创建存储桶、管理其生命周期并管理对它们的访问。

API

COSI API 以桶为中心,因为桶是对象存储的单元抽象。COSI 定义了三个旨在管理它们的 Kubernetes API

  • Bucket
  • BucketClass
  • BucketClaim

此外,还定义了另外两个用于管理对存储桶的访问的 API:

  • BucketAccess
  • BucketAccessClass

简而言之,Bucket 和 BucketClaim 可以认为分别类似于 PersistentVolume 和 PersistentVolumeClaim。BucketClass 在文件/块设备世界中的对应物是 StorageClass。

由于对象存储始终通过网络进行身份验证,因此需要访问凭证才能访问存储桶。BucketAccess 和 BucketAccessClass 这两个 API 用于表示访问凭证和身份验证策略。有关这些 API 的更多信息可以在官方 COSI 提案中找到:

https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support

Self-Service

除了提供 kubernetes-API 驱动的存储桶管理之外,COSI 还旨在使 DevOps 人员能够自行配置和管理存储桶,而无需管理员干预。这进一步使开发团队能够实现更快的周转时间和更快的上市时间。

COSI 通过在两个不同的利益相关者(即管理员 admin 和集群操作员)之间划分存储桶配置步骤来实现这一点。管理员将负责就如何配置存储桶以及如何获取存储桶的访问权限设置广泛的策略和限制。集群操作员可以在管理员设置的限制内自由创建和使用存储桶。

例如,集群操作员可以使用管理策略将最大预置容量限制为 100GB,并且允许开发人员创建存储桶并将数据存储到该限制。同样对于访问凭证,管理员将能够限制谁可以访问哪些存储桶,并且开发人员将能够访问他们可用的所有存储桶。

可移植性

COSI 的第三个目标是实现存储桶管理的供应商中立性。COSI 支持两种可移植性:

  • 跨集群
  • 跨提供商

跨集群可移植性允许在一个集群中配置的存储桶在另一个集群中可用。这仅在对象存储后端本身可以从两个集群访问时才有效。

跨提供商可移植性是指允许组织或团队无缝地从一个对象存储提供商迁移到另一个对象存储提供商,而无需更改应用程序定义(PodTemplates、StatefulSets、部署等)。这只有在源和目标提供者使用相同的数据时才有可能。

COSI 不处理数据迁移,因为它超出了其范围。如果提供商之间的移植也需要迁移数据,则需要采取其他措施来确保数据可用性。

下一步

令人惊叹的 sig-storage-cosi 社区一直在努力将 COSI 标准带入 alpha 状态。我们期待很多供应商加入编写 COSI 驱动程序并与 COSI 兼容!

我们希望为 COSI 存储桶添加更多身份验证机制,我们正在设计高级存储桶共享原语、多集群存储桶管理等等。未来有很多伟大的想法和机会!

链接:https://kubernetes.io/blog/2022/09/02/cosi-kubernetes-object-storage-management/

本文链接:https://www.yunweipai.com/43100.html

网友评论comments

发表回复

您的电子邮箱地址不会被公开。

暂无评论

Copyright © 2012-2022 YUNWEIPAI.COM - 运维派 京ICP备16064699号-6
扫二维码
扫二维码
返回顶部