Kubernetes CSI 和 COSI：共生关系

近几个月来，Kubernetes 中对象存储标准化的推动势头强劲。名为 COSI for Container Object Storage Interface的新标准与 CSI 有着相似的共鸣——CSI 是 Kubernetes 中众所周知的存储消费标准。

在本文中，我将深入探讨 COSI、它的体系结构以及它如何与 CSI 配合使用。最后介绍一下MinIO自带的CSI驱动——DirectCSI。

容器对象存储接口

COSI 是一组 API，可自动配置和管理 Kubernetes 中的对象存储桶。除了自动化，COSI 还承诺：

• 供应商独立性

• 跨集群可移植性

本质上，COSI 的消费者将能够以一种自动化的、与供应商无关的方式将对象存储用于他们的工作负载，同时保留将他们的工作负载转移到不同平台/对象存储供应商的能力，而无需对其工作负载定义进行任何更改*。

用户将能够在他们的 PodSpec（工作负载规范）中指定对存储桶的需求，COSI 将启动以在后端创建存储桶，生成用于访问它的凭证，并将存储桶及其访问凭证提供给请求它的 Pod。COSI 还会在使用存储桶完成工作负载时自动拆除和撤销访问权限。

为了实现这一目标，COSI 使用标准化的 gRPC API 与对象存储供应商集成，允许任何对象存储供应商与 COSI 兼容。

建筑学

下图描述了 COSI 的关键集成点及其在云原生环境中的位置：

犯罪现场调查

CSI 是一组 API，可自动配置和管理块设备和文件系统。这是 COSI 和 CSI 之间的根本区别。

在需要块存储和对象存储的 Kubernetes 集群中——COSI 和 CSI 驱动程序可以同时运行。事实上，MinIO 部署遵循同样的架构，其中对象存储由 MinIO 提供，而 MinIO 服务器本身的驱动器由 CSI 驱动程序提供。

直接CSI

MinIO 专门构建了自己的 CSI 驱动程序，称为 DirectCSI。

DirectCSI 为在 Kubernetes 中运行的容器化工作负载提供和管理块设备。与绝大多数 CSI 驱动程序相比，DirectCSI 的关键区别在于它为工作负载提供了对本地驱动器的直接访问权限——顾名思义。

像 MinIO 这样的高性能应用程序需要直接访问。由于 MinIO 自行管理数据的持久性、可用性和加密，因此提供远程驱动器（与本地驱动器相比）的 CSI 层只会成为性能瓶颈。

MinIO 之类的存储应用程序无法从传统上通过使用远程驱动器获得的任何价值中获益——数据持久性、静态加密、可用性等。

DirectCSI 管理在可用空间可用的节点上调度工作负载的复杂性，以确保工作负载仅使用它们运行所在节点的本地驱动器。

今天就试用 DirectCSI，访问https://github.com/minio/direct-csi开始吧！

*COSI 不会自动将数据从一个存储桶传输到另一个存储桶。