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

Posted 2023-03-04

【中文标题】Kubernetes 本地/csi PV 内容是不是同步到新节点？

【英文标题】：Is Kubernetes local/csi PV content synced into a new node?Kubernetes 本地/csi PV 内容是否同步到新节点？

【发布时间】：2021-08-11 17:21:51

【问题描述】：

根据the documentation：

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

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

CSI 本地

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

但是also:

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

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

用例

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

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

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

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

【问题讨论】：

你能找到任何解决本地卷复制的方法吗？

@ImranRazaKhan 不幸的是不是开箱即用的，所以我不得不使用rsync 进行手动复制，然后切换到供应商为 Kubernetes 卷提供的解决方案，从而处理向供应商的复制。

如果您只有 2 个节点，

rsync 或 lsyncd 很好，我正在评估使用 DRBD 的选项。

@ImranRazaKhan Syncthing 也不错，虽然它可能太大了。再次，它提供了API，因此可以在需要时进行远程调整。

【参考方案1】：

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

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

您引用的卷类型：

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

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

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

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

【讨论】：

听起来很糟糕，但很合理。我想从技术上讲，为负责复制的软件实现第 3 方驱动程序比在编排器本身中弄乱复制要容易得多。谢谢你的解释！