介绍 DirectPV

DirectPV 是用于直接附加存储的 CSI 驱动程序。在最基本的层面上，它是一个分布式持久卷管理器，而不是像 SAN 或 NAS 这样的存储系统。DirectPV 用于跨服务器发现、格式化、安装、调度和监控驱动器。

在我们进入 DirectPV 的体系结构之前，让我们先说明为什么我们需要构建它。

历史

对象存储、数据库、消息队列和 AI/ML/分析工作负载等现代分布式数据存储设计为在带有本地连接驱动器的商用现成服务器上运行。由于他们已经处理了擦除编码或复制和高可用性等关键存储功能，因此他们所需要的只是直接本地访问 JBOD 配置中的哑商品驱动器（只是一堆驱动器）。在 Kubernetes 环境中为这些分布式数据服务使用网络附加存储 (NAS) 和存储区域网络 (SAN) 硬件设备既效率低下，也是 Kubernetes 反模式。您将复制已经复制的数据，同时在驱动器和主机之间引入第二个网络跃点。两者都不是必需的。即使对于超融合基础设施。

LocalPV 与 NetworkPV

Kubernetes 很早就通过 Hostpath 和 LocalPV 功能引入了对本地附加存储的原始支持。然而，自从引入 Kubernetes 容器存储接口 (CSI) 驱动程序模型后，这项工作就留给了存储供应商，以将功能扩展到核心 Kubernetes 之外。

API 不支持本地 PV 或网络 PV 方法。它是用 API 应有的抽象 API 术语编写的。当时，持久卷市场由 SAN 供应商主导。这只是一个事实，即从历史上看，存储供应商都是文件和块供应商。即使在今天，与对象存储供应商相比，SAN 和 NAS 供应商也要多得多——尽管主要工作负载的对象存储在增长。随着时间的推移，这将自行解决。但我们离题了。

因为有更多的 SAN 或 NAS 供应商，并且因为它们在设计上不是云原生的（POSIX 与 S3/RESTful API），所以他们非常努力地谈论 CSI 作为桥接解决方案。

在应用程序领域，SAN/NAS 供应商花费了过多的时间来谈论分解。在他们的叙述中，分解是在无状态微服务和容器与数据存储等有状态服务之间进行的。这些数据存储的示例包括 MinIO、Cassandra 和 Kafka。

存储供应商急于为他们的 SAN 和 NAS 硬件设备提供 Kubernetes CSI 驱动程序，但他们没有既得利益来实施会蚕食他们自己产品的 CSI 驱动程序。VMware 是第一个认识到这个问题的人，他们引入了vSAN Direct来解决这个 LocalPV 问题。但是，此解决方案仅提供给 VMware Tanzu 客户。

接下来的第二个是OpenEBS LocalPV，它提供本地和网络持久卷。LongHorn等其他公司计划支持 LocalPV 功能 ( https://github.com/longhorn/longhorn/issues/3957 )。

介绍 DirectPV

因为 MinIO 是从头开始构建的，所以我们的许多 MinIO 部署都在 Kubernetes 上。我们经常处理每个机箱托管 12 到 108 个驱动器的 JBOD。虽然我们喜欢 Kubernetes 原生 LocalPV 的简单性，但它并没有在操作上进行扩展。卷必须静态预配置，并且没有简单的方法来管理大量驱动器。此外，LocalPV 缺乏 CSI 驱动程序模型的复杂性。

考虑到 MinIO 的极简设计理念，我们寻求一个动态的 LocalPV CSI 驱动程序实现，它具有有用的卷管理功能，如驱动器发现、格式化、配额和监控。市场上没有，所以我们做了我们一直做的事，我们制造了一个。

因此引入了 Direct Persistent Volume - https://min.io/directpv。

DirectPV 是用于直接附加存储 ( DAS )的 Kubernetes 容器存储接口 (CSI) 驱动程序。一旦本地卷被配置并附加到容器，DirectPV 就不会妨碍应用程序 I/O。所有读取和写入都直接在卷上执行。您可以期望性能与本地驱动器一样快。MinIO、Cassandra、Kafka、Elastic、MongoDB、Presto、Trino、Spark 和 Splunk 等分布式有状态服务将从 DirectPV 驱动程序中受益匪浅，以满足其热层需求。为了长期持久化，他们可能会使用 MinIO 对象存储作为暖层。MinIO 将依次使用 DirectPV 将数据写入持久存储介质。

这有效地将行业从传统的基于 SAN 和 NAS 的存储系统中解放出来。

DirectPV 内部结构

控制器

进行卷声明时，控制器会从空闲驱动器池中统一配置卷。DirectPV 知道 pod 的关联约束，并将卷从本地驱动器分配给 pod。请注意，每个集群仅运行一个控制器的活动实例。

节点驱动程序

Node Driver 实现节点上驱动器的发现、格式化、挂载和监控等卷管理功能。节点驱动程序的一个实例在每个存储服务器上运行。

用户界面

存储管理员可以使用 kubectl CLI 插件来选择、管理和监控驱动器。集成的网络用户界面目前正在开发中。

试一试！

DirectPV 完全开源，安装简单。只需两步。成功安装 DirectPV krew 插件后，请尝试使用 info 命令以确保安装成功。

接下来，您会发现所有驱动器并将它们置于 DirectPV 管理之下。从现在开始，这些驱动器将由 Kubernetes 容器的 DirectPV 专门管理。

$ kubectl directpv 驱动器 ls

$ kubectl directpv drives format -drives /dev/sd{a…f} -nodes directpv-{1…n}

您的驱动器现在已准备好动态配置为 LocalPV。Pod 将自动获得与具有匹配 LocalPV 的节点的亲和力。要进行卷声明，请使用 directpv 作为 PodSpec.VolumeClaimTemplates 中的存储类。

结语

您会立即注意到 Direct Persistent Volume 的效率和简单性。去除了整个复杂层。应用程序通过数据存储直接与其数据对话，消除了遗留的 SAN/NAS 层。DirectPV 消除了所有额外的网络硬件要求，所有额外的附加管理。

DirectPV 的优势在于其简约的设计。结果它解决了 LocalPV 问题 - 但只是那个问题。我们没有任何计划添加对 NetworkPV 的支持，因为它们适用于遗留应用程序，并且市场上有多种解决方案可以解决这些问题。