这篇文章已经超过一年了。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。
介绍 COSI:使用 Kubernetes API 的对象存储管理
本文介绍了容器对象存储接口 (COSI),这是在 Kubernetes 中配置和使用对象存储的标准。它是 Kubernetes v1.25 中的一个 alpha 功能。
文件和块存储通过 容器存储接口 (CSI) 在 Kubernetes 生态系统中被视为一等公民。使用 CSI 卷的工作负载可以享受跨供应商和跨 Kubernetes 集群的便携性优势,而无需更改应用程序清单。对于对象存储,不存在等效的标准。
近年来,对象存储作为文件系统和块设备的替代存储形式越来越受欢迎。对象存储范式促进了计算和存储的分离。这是通过在网络上提供数据而不是在本地提供数据来实现的。分离的架构允许计算工作负载是无状态的,这使得它们更容易管理、扩展和自动化。
COSI
COSI 旨在标准化对象存储的使用,以提供以下好处
- Kubernetes 原生 - 使用 Kubernetes API 来配置、设置和管理存储桶
- 自助服务 - 在管理和操作(DevOps)之间明确划分,以便为 DevOps 人员启用自助服务功能
- 便携性 - 通过跨 Kubernetes 集群和跨对象存储供应商的便携性实现供应商中立性
只有当供应商都支持通用的数据路径 API 时,才有可能实现跨供应商的移植。例如,可以从 AWS S3 移植到 Ceph,或从 AWS S3 移植到 MinIO,然后再移植回来,因为它们都使用 S3 API。相比之下,不可能从 AWS S3 移植到 Google Cloud 的 GCS 或反之亦然。
架构
COSI 由三个组件组成
- COSI 控制器管理器
- COSI Sidecar
- COSI 驱动程序
COSI 控制器管理器充当主控制器,处理对 COSI API 对象的更改。它负责处理创建、更新、删除存储桶和访问管理的请求。每个 Kubernetes 集群需要一个控制器管理器实例。即使集群中使用多个对象存储提供商,也只需要一个。
COSI Sidecar 充当 COSI API 请求和供应商特定的 COSI 驱动程序之间的转换器。此组件使用供应商驱动程序应满足的标准化 gRPC 协议。
COSI 驱动程序是供应商特定的组件,它接收来自 Sidecar 的请求,并调用相应的供应商 API 来创建存储桶、管理其生命周期以及管理对其的访问。
API
COSI API 以存储桶为中心,因为存储桶是对象存储的单位抽象。COSI 定义了三个旨在管理它们的 Kubernetes API
- 存储桶 (Bucket)
- 存储桶类 (BucketClass)
- 存储桶声明 (BucketClaim)
此外,还定义了另外两个用于管理存储桶访问的 API
- 存储桶访问 (BucketAccess)
- 存储桶访问类 (BucketAccessClass)
简而言之,存储桶和存储桶声明可以分别被视为类似于持久卷和持久卷声明。存储桶类在文件/块设备世界中的对应物是存储类。
由于对象存储始终需要身份验证,并且通过网络进行访问,因此需要访问凭据才能访问存储桶。这两个 API,即存储桶访问和存储桶访问类用于表示身份验证的访问凭据和策略。有关这些 API 的更多信息,可以在官方 COSI 提案中找到 - https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support
自助服务
除了提供 Kubernetes API 驱动的存储桶管理外,COSI 还旨在使 DevOps 人员能够自己配置和管理存储桶,而无需管理员干预。这进一步使开发团队能够实现更快的周转时间和更快的上市时间。
COSI 通过在两个不同的利益相关者(即管理员 (admin) 和集群操作员)之间划分存储桶配置步骤来实现这一点。管理员将负责设置关于如何配置存储桶以及如何获得对其的访问权限的广泛策略和限制。集群操作员可以在管理员设置的限制范围内自由创建和使用存储桶。
例如,集群操作员可以使用管理员策略将最大配置容量限制为 100GB,并且允许开发人员创建存储桶并将数据存储到该限制。同样,对于访问凭据,管理员将能够限制谁可以访问哪些存储桶,开发人员将能够访问所有可用的存储桶。
便携性
COSI 的第三个目标是实现存储桶管理的供应商中立性。COSI 实现了两种便携性
- 跨集群
- 跨提供商
跨集群便携性允许在一个集群中配置的存储桶在另一个集群中可用。这仅在可以从两个集群访问对象存储后端本身时才有效。
跨提供商便携性是指允许组织或团队无缝地从一个对象存储提供商迁移到另一个对象存储提供商,而无需更改应用程序定义(PodTemplates、StatefulSets、Deployment 等)。只有当源提供商和目标提供商使用相同的数据时,这才是可能的。
COSI 不处理数据迁移,因为它超出其范围。如果提供商之间的移植也需要迁移数据,则需要采取其他措施来确保数据的可用性。
下一步是什么
优秀的 sig-storage-cosi 社区一直在努力将 COSI 标准提升到 alpha 状态。我们期待着许多供应商编写 COSI 驱动程序并变得 COSI 兼容!
我们希望为 COSI 存储桶添加更多的身份验证机制,我们正在设计高级存储桶共享原语、多集群存储桶管理等等。前面有很多很棒的想法和机会!
请继续关注下一步的内容,如果您有任何问题、意见或建议
- 在 Kubernetes Slack:#sig-storage-cosi 上与我们聊天
- 加入我们的 Zoom 会议,每周四太平洋时间上午 10:00
- 参与 存储桶 API 提案 PR,添加您的想法、建议等。