时间戳

首页 > 解决方案 > Kubernetes 本地/csi PV 内容是否同步到新节点？

kubernetes - Kubernetes 本地/csi PV 内容是否同步到新节点？

问题描述

根据文档：

PersistentVolume (PV) 是集群中已配置的一块存储……它是集群中的资源，就像节点是集群资源一样……

所以我正在阅读所有当前可用的 PV插件，并且我知道对于 3rd-party/集群外存储这并不重要（例如将数据存储在 EBS、Azure 或 GCE 磁盘中），因为没有或很少从集群中添加或删除节点时的影响。但是，有不同的，例如（忽略hostPath它仅适用于单节点集群）：

其中（至少从我在文档中读到的内容）不需要第 3 方供应商/软件。

但也：

...本地卷取决于底层节点的可用性，并不适合所有应用程序。如果节点变得不健康，则 pod 将无法访问本地卷。使用此卷的 pod 无法运行。使用本地卷的应用程序必须能够容忍这种降低的可用性以及潜在的数据丢失，具体取决于底层磁盘的持久性特征。

如果不使用外部静态配置器来管理卷生命周期，则本地 PersistentVolume 需要用户手动清理和删除。

用例

假设我有一个带有单个localPV 的单节点集群，并且我想向集群中添加一个新节点，所以我有 2 节点集群（为简单起见，数字很小）。

来自现有localPV 的数据是否会像拥有一个具有 2 个冗余节点的 PV 一样 1:1 复制到新节点中，还是仅严格绑定到现有节点？

如果已经存在的 PV 无法从 1 个节点调整到 2 个节点，是否可以创建一个新的 PV（从头开始创建）以便在集群上的 2 个以上节点之间 1:1 复制？

或者，如果不是，那么不使用第 3 方集群外解决方案的正确方法是什么？使用csi会导致整体方法发生任何变化，还是与冗余相同，只是引擎盖下的“引擎”不同？

标签： kubernetespersistent-storage

解决方案

是否可以创建一个新的 PV，以便在集群上的 2 个以上节点之间进行 1:1 复制？

根本不复制任何标准卷类型。如果您可以使用支持ReadWriteMany访问的卷类型（最容易使用 NFS），那么多个 pod 可以同时使用它，但您必须运行匹配的 NFS 服务器。

您引用的卷类型：

  • hostPath是 Pod 恰好在其上运行的节点上的目录。它不是任何特定节点上的目录，因此如果 pod 在不同节点上重新创建，它将引用同一目录但在新节点上，可能具有不同的内容。除了基本的测试场景外，我不确定hostPathPersistentVolume 何时有用。

  • local是特定节点上的目录，或至少遵循节点关联性约束。Kubernetes 知道并非所有存储都可以挂载在每个节点上，因此这会自动限制 pod 在具有该目录的节点上运行（假设该节点仍然存在）。

  • csi是一种非常通用的扩展机制，因此您可以运行不在您链接到的列表中的存储驱动程序。存储后端的 CSI 版本可能比 in-tree 版本更好地支持某些功能。（我熟悉 AWS：EBS CSI 驱动程序支持快照和调整大小；EFS CSI 驱动程序可以动态预置 NFS 目录。）

在本地测试集群的特定情况下（例如，使用kind），使用local卷将限制 pod 在具有数据的节点上运行，这比使用hostPath卷更健壮。但是，它不会复制数据，因此如果删除了包含数据的节点，数据也会随之消失。

推荐阅读