常见问题解答

DirectPV 特别适用于直接连接存储，例如“JBOD”配置（Just a Bunch of Disks）中的硬盘驱动器和固态驱动器。

避免将 DirectPV 与基于 SAN 和 NAS 的存储选项一起使用，因为它们在数据路径中固有地涉及额外的网络跳跃。这会导致性能低下和复杂性增加。

HostPath 卷是临时的，并且与 Pod 的生命周期绑定在一起。删除或重启 Pod 会导致删除 HostPath 卷。这会导致存储在卷上的任何数据丢失。

DirectPV 卷在节点和 Pod 重启后都将保留。相关的持久卷声明 (PVC) 管理 DirectPV 卷的生命周期。

LocalPV 从需要持久卷的节点上的本地存储资源中进行静态配置。您必须在使用 LocalPV 的工作负载之前创建所需的 LocalPV。对于 LocalPV，您必须为所有阶段提供广泛的用户管理，包括为 LocalPV 创建实际的对象资源。

DirectPV 也会创建静态配置的卷资源，但不需要用户干预即可创建对象资源。相反，DirectPV 会动态配置持久卷，以响应请求 DirectPV 存储卷的 PVC。这显着降低了管理的复杂性。

DirectPV 仅在显式管理的磁盘上运行。

对于这些受管理的磁盘，DirectPV

1. 选择调度 Pod 所在节点的本地磁盘，为 Pod 提供对磁盘的直接访问。

2. 运行选择算法来为卷创建请求选择一个磁盘。

3. 为卷创建一个子目录，并为请求的卷大小设置子目录的配额。

4. 将卷发布到 Pod。

使用 kubectl directpv init 以 XFS 文件系统格式化驱动并将其挂载到所需路径 (/var/lib/directpv/mnt/<uuid>) 来准备驱动。成功挂载后，DirectPV 可以在这些驱动上调度卷。要查看已初始化的驱动，请使用 kubectl directpv list drives。

要初始化，驱动必须至少有 512MB 的空间。驱动 **不能** 具有以下任何特征：

• 隐藏

  (/sys/class/block/<device>/hidden 不应为“1”。)

• 只读

• 已分区

• 被其他设备占用

  (/sys/class/block/<device>/holders 不应有任何条目。)

• 已挂载

• 已启用交换空间

• 是 CD-ROM

DirectPV 支持任何以块设备形式呈现的存储资源。虽然这包括 LVM（逻辑卷管理）、LUK（Linux 统一密钥）、LUN（逻辑单元号）以及类似的虚拟化驱动，但我们不建议在生产环境中使用 DirectPV 与此类设备。

此错误会在以下情况下发生：

• Kubernetes 将 Pod 调度到 DirectPV 未初始化任何驱动器的节点上。要纠正此问题，请在工作负载中使用选择器，以便 Kubernetes 将 Pod 调度到所需的一组节点上。有关更多详细信息，请参阅 Kubernetes 文档中关于将 Pod 分配到节点 的内容。
• 您请求的区域、大小或其他此类参数，DirectPV 无法在所选节点上使用可用的已初始化驱动满足这些参数。要纠正此问题，请在工作负载中将参数更改为可用的一组值。

否，DirectPV v4.0.0 及更高版本已不再支持 direct-csi-min-io。在此版本之后，DirectPV 不会使用 direct-csi-min-io 存储类配置任何新卷。但是，最新版本的 DirectPV 继续管理已使用 direct-csi-min-io 存储类配置的任何现有卷。

要配置新卷，请使用 directpv-min-io 存储类。direct-csi-min-io 和 directpv-min-io 之间没有功能或行为差异。

否，DirectPV 不支持 CSI 快照。DirectPV 特别适用于应用程序负责数据可用性和弹性用例，例如 MinIO。使用 AWS S3 版本控制 API 和内部修复功能的应用程序不需要快照。

否，DirectPV 不支持 ReadWriteMany。DirectPV 仅支持 ReadWriteOnce。

使用 DirectPV 的工作负载在节点上本地运行。DirectPV 从节点上的本地磁盘配置卷。这允许工作负载直接访问数据路径，而无需任何额外的网络跳转，与远程卷（网络 PV）不同。

来自联网持久卷的额外网络跳转会增加工作负载的复杂性，并可能导致性能下降。