本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否仍准确。

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

作者：Sidhartha Mani (Minio, Inc) |

本文介绍容器对象存储接口 (COSI)，这是一个用于在 Kubernetes 中供应和使用对象存储的标准。它是 Kubernetes v1.25 的 Alpha 特性。

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

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

COSI

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

  • Kubernetes 原生 - 使用 Kubernetes API 供应、配置和管理 Bucket
  • 自助服务 - 管理与运维 (DevOps) 之间清晰的界限，为 DevOps 人员提供自助服务能力
  • 可移植性 - 通过跨 Kubernetes 集群和跨对象存储供应商的可移植性实现供应商中立性

跨供应商的可移植性只有在两个供应商都支持通用的数据路径 API 时才可能实现。例如，由于它们都使用 S3 API，因此可以从 AWS S3 迁移到 Ceph，或从 AWS S3 迁移到 MinIO，然后再迁回。相比之下，无法从 AWS S3 迁移到 Google Cloud 的 GCS 或反之亦然。

架构

COSI 由三个组件组成：

  • COSI Controller Manager
  • COSI Sidecar
  • COSI Driver

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

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

COSI Driver 是供应商特定的组件，接收 Sidecar 的请求并调用相应的供应商 API 来创建 Bucket、管理其生命周期和管理对它们的访问。

API

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

  • Bucket
  • BucketClass
  • BucketClaim

此外，还定义了两个用于管理 Bucket 访问的 API：

  • BucketAccess
  • BucketAccessClass

简而言之，Bucket 和 BucketClaim 可以分别类比为 PersistentVolume 和 PersistentVolumeClaim。BucketClass 在文件/块设备领域的对应物是 StorageClass。

由于对象存储始终需要认证并通过网络访问，因此访问 Bucket 需要访问凭据。这两个 API，即 BucketAccess 和 BucketAccessClass，用于表示访问凭据和认证策略。有关这些 API 的更多信息，请参阅官方 COSI 提案 - https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support

自助服务

除了提供由 Kubernetes API 驱动的 Bucket 管理之外，COSI 还旨在赋能 DevOps 人员独立供应和管理 Bucket，无需管理员干预。这进一步使开发团队能够实现更快的周转时间和更快的上市时间。

COSI 通过将 Bucket 供应步骤分配给两个不同的利益相关者来实现这一点，即管理员 (admin) 和集群操作员。管理员负责设置关于如何供应 Bucket 以及如何获取对它们的访问的广泛策略和限制。集群操作员可以在管理员设定的限制内自由创建和使用 Bucket。

例如，集群操作员可以使用管理员策略将最大供应容量限制为 100GB，开发者将被允许创建 Bucket 并存储数据直到达到该限制。同样对于访问凭据，管理员可以限制谁可以访问哪些 Bucket，而开发者将能够访问所有对他们可用的 Bucket。

可移植性

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

  • 跨集群
  • 跨提供商

跨集群可移植性是指允许在一个集群中供应的 Bucket 在另一个集群中可用。这仅在对象存储后端本身可从两个集群访问时才有效。

跨提供商可移植性是指允许组织或团队无缝地从一个对象存储提供商迁移到另一个，并且无需更改应用定义 (如 PodTemplate、StatefulSet、Deployment 等)。

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

后续计划

令人惊叹的 sig-storage-cosi 社区一直努力将 COSI 标准推向 Alpha 阶段。我们期待众多供应商加入，编写 COSI 驱动并实现 COSI 兼容！

我们希望为 COSI Bucket 添加更多认证机制，我们正在设计高级 Bucket 共享原语、多集群 Bucket 管理等等。前面有很多很棒的想法和机会！

敬请关注后续动态，如果您有任何问题、意见或建议，请：

  • 在 Kubernetes Slack 上与我们聊天：#sig-storage-cosi
  • 加入我们的 Zoom 会议，太平洋时间每周四上午 10:00
  • 参与 Bucket API 提案的 PR，提交你的想法、建议等。