本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

介绍 COSI：使用 Kubernetes API 进行对象存储管理

作者：Sidhartha Mani (Minio, Inc) |

本文介绍了容器对象存储接口（Container Object Storage Interface，COSI），这是在 Kubernetes 中供应和使用对象存储的标准。它是 Kubernetes v1.25 中的一个 Alpha 功能。

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

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

COSI

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

  • Kubernetes 原生 - 使用 Kubernetes API 来供应、配置和管理存储桶（bucket）
  • 自助服务 - 明确划分管理和运营（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 边车充当 COSI API 请求和特定于供应商的 COSI 驱动程序之间的转换器。该组件使用供应商驱动程序应满足的标准化 gRPC 协议。

COSI 驱动程序是特定于供应商的组件，它从边车接收请求，并调用相应的供应商 API 来创建存储桶、管理其生命周期以及管理对其的访问。

API

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

  • Bucket
  • BucketClass
  • BucketClaim

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

  • BucketAccess
  • BucketAccessClass

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

由于对象存储总是经过身份验证并通过网络访问，因此需要访问凭证来访问存储桶。这两个 API，即 BucketAccess 和 BucketAccessClass，用于表示访问凭证和身份验证策略。有关这些 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 存储桶添加更多身份验证机制，我们正在设计高级的存储桶共享原语、多集群存储桶管理等等。前方有许多伟大的想法和机会！

敬请关注接下来的内容，如果您有任何问题、评论或建议：