常见问题解答

DirectPV 是专门用于直连存储例如在"JBOD"配置中的硬盘驱动器和固态驱动器（只是一堆磁盘）。

避免将 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（逻辑卷管理）、LUKS（Linux统一密钥设置）、LUN（逻辑单元号）和类似的虚拟化驱动器，但我们不建议在生产环境中将DirectPV与此类设备一起使用。

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

• Kubernetes scheduled the pod on a node where DirectPV doesn’t have any drives initialized. To correct this, use selectors in the workload to have Kubernetes schedule the pods on the desired set of nodes. Refer to theKubernetes 关于将 Pod 分配到节点的文档更多详情。
• 您请求的区域、大小或其他此类参数无法通过所选节点上可用的已初始化驱动器来满足 DirectPV 的要求。 要纠正此问题，请将工作负载中的参数更改为一组可用的值。

不，DirectPV v4.0.0 及更高版本移除了对direct-csi-min-io在此版本之后，DirectPV 不再使用direct-csi-min-iostorage class。 但是，最新版本的 DirectPV 将继续管理任何已使用该存储类配置的现有卷。direct-csi-min-io存储类。

要配置新卷，请使用directpv-min-io存储类。 在功能或行为上没有区别direct-csi-min-io和directpv-min-io.

不，DirectPV 不支持 CSI 快照功能。 DirectPV 专门针对应用程序自行处理数据可用性和弹性的使用场景设计，例如MinIO使用 AWS S3 版本控制 API 和内部修复功能的应用程序不需要快照。

不，DirectPV 不支持ReadWriteManyDirectPV 仅支持ReadWriteOnce.

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

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