Kubernetes CSI 和 COSI：共生关系

近年来，在 Kubernetes 中标准化对象存储的呼声越来越高。新的标准名为 COSI，代表 *Container Object Storage Interface*，与 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 驱动程序提供。

MinIO 专为其自身构建了名为 DirectCSI 的 CSI 驱动程序。

DirectCSI 为运行在 Kubernetes 中的容器化工作负载配置和管理块设备。与大多数 CSI 驱动程序相比，DirectCSI 的主要区别在于它为工作负载提供了对本地驱动器的直接访问权限 —— 正如其名称所暗示的那样。

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

像 MinIO 这样的存储应用程序无法从使用远程驱动程序通常获得的任何价值中获益 —— 数据持久性、静止加密、可用性等。

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

立即体验 DirectCSI，访问 https://github.com/minio/direct-csi 开始吧！

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