Kubernetes local/csi PV 内容是否同步到新节点？
Is Kubernetes local/csi PV content synced into a new node?
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned ... It is a resource in the cluster just like a node is a cluster resource...
所以我正在阅读所有当前可用的 plugins PV 并且我知道对于第 3 方/集群外存储这并不重要（例如将数据存储在 EBS、Azure 或 GCE 中磁盘），因为在集群中添加或删除节点时没有影响或影响很小。但是，有不同的，例如（忽略 hostPath 因为它仅适用于单节点集群）：
- csi
- 本地
哪个（至少从我在文档中读到的）不需要第 3 方 vendors/software。
但是also:
... local volumes are subject to the availability of the underlying node and are not suitable for all applications. If a node becomes unhealthy, then the local volume becomes inaccessible by the pod. The pod using this volume is unable to run. Applications using local volumes must be able to tolerate this reduced availability, as well as potential data loss, depending on the durability characteristics of the underlying disk.
The local PersistentVolume requires manual cleanup and deletion by the user if the external static provisioner is not used to manage the volume lifecycle.
用例
假设我有一个带有单个 local PV 的单节点集群，我想向该集群添加一个新节点，因此我有 2 节点集群（为简单起见，数量较少）。
来自现有 local PV 的数据是否会被 1:1 复制到新节点中，就像一个 PV 具有 2 个冗余节点一样，还是仅严格绑定到现有节点？
如果无法将现有 PV 从 1 个节点调整为 2 个节点，是否可以创建 新 PV（从头开始创建）以便 1:1 复制在集群上的 2 个以上节点之间？
或者，如果不是，那么不使用第 3 方集群外解决方案的正确方法是什么？使用 csi 会导致整体方法发生任何变化，还是与冗余相同，只是引擎盖下的“引擎”不同？
Can a new PV be created so it's 1:1 replicated between 2+ nodes on the cluster?
None 个标准卷类型已完全复制。如果您可以使用支持 ReadWriteMany 访问的卷类型（最常见的 NFS），那么多个 pods 可以同时使用它，但您必须 运行 匹配的 NFS 服务器。
您引用的卷类型中：
hostPath 是 pod 恰好 运行 所在的节点上的一个目录。它不是任何特定节点上的目录，因此如果在不同节点上重新创建 pod，它将引用同一目录但在新节点上，可能具有不同的内容。除了基本的测试场景，我不确定 hostPath PersistentVolume 什么时候有用。
local 是特定节点上的目录，或者至少遵循节点亲和性约束。 Kubernetes 知道并非所有存储都可以安装在每个节点上，因此这会自动将 pod 限制为具有目录的节点上的 运行（假设该节点仍然存在）。
csi 是一种极其通用的扩展机制，因此您可以 运行 不在列表中的存储驱动程序 link。存储后端的 CSI 版本可能比树内版本更好地支持某些功能。 （我熟悉 AWS：EBS CSI driver supports snapshots and resizing; the EFS CSI driver 可以动态配置 NFS 目录。）
在本地测试集群的特定情况下（例如，使用 kind），使用 local 卷将限制节点上的 pods 到 运行数据，这比使用 hostPath 卷更可靠。但是，它不会复制数据，因此如果删除包含数据的节点，数据也会随之消失。
A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned ... It is a resource in the cluster just like a node is a cluster resource...
所以我正在阅读所有当前可用的 plugins PV 并且我知道对于第 3 方/集群外存储这并不重要（例如将数据存储在 EBS、Azure 或 GCE 中磁盘），因为在集群中添加或删除节点时没有影响或影响很小。但是，有不同的，例如（忽略 hostPath 因为它仅适用于单节点集群）：
- csi
- 本地
哪个（至少从我在文档中读到的）不需要第 3 方 vendors/software。
但是also:
... local volumes are subject to the availability of the underlying node and are not suitable for all applications. If a node becomes unhealthy, then the local volume becomes inaccessible by the pod. The pod using this volume is unable to run. Applications using local volumes must be able to tolerate this reduced availability, as well as potential data loss, depending on the durability characteristics of the underlying disk.
The local PersistentVolume requires manual cleanup and deletion by the user if the external static provisioner is not used to manage the volume lifecycle.
用例
假设我有一个带有单个 local PV 的单节点集群，我想向该集群添加一个新节点，因此我有 2 节点集群（为简单起见，数量较少）。
来自现有 local PV 的数据是否会被 1:1 复制到新节点中，就像一个 PV 具有 2 个冗余节点一样，还是仅严格绑定到现有节点？
如果无法将现有 PV 从 1 个节点调整为 2 个节点，是否可以创建 新 PV（从头开始创建）以便 1:1 复制在集群上的 2 个以上节点之间？
或者，如果不是，那么不使用第 3 方集群外解决方案的正确方法是什么？使用 csi 会导致整体方法发生任何变化，还是与冗余相同，只是引擎盖下的“引擎”不同？
Can a new PV be created so it's 1:1 replicated between 2+ nodes on the cluster?
None 个标准卷类型已完全复制。如果您可以使用支持 ReadWriteMany 访问的卷类型（最常见的 NFS），那么多个 pods 可以同时使用它，但您必须 运行 匹配的 NFS 服务器。
您引用的卷类型中：
hostPath是 pod 恰好 运行 所在的节点上的一个目录。它不是任何特定节点上的目录，因此如果在不同节点上重新创建 pod，它将引用同一目录但在新节点上，可能具有不同的内容。除了基本的测试场景，我不确定hostPathPersistentVolume 什么时候有用。local是特定节点上的目录，或者至少遵循节点亲和性约束。 Kubernetes 知道并非所有存储都可以安装在每个节点上，因此这会自动将 pod 限制为具有目录的节点上的 运行（假设该节点仍然存在）。csi是一种极其通用的扩展机制，因此您可以 运行 不在列表中的存储驱动程序 link。存储后端的 CSI 版本可能比树内版本更好地支持某些功能。 （我熟悉 AWS：EBS CSI driver supports snapshots and resizing; the EFS CSI driver 可以动态配置 NFS 目录。）
在本地测试集群的特定情况下（例如，使用 kind），使用 local 卷将限制节点上的 pods 到 运行数据，这比使用 hostPath 卷更可靠。但是，它不会复制数据，因此如果删除包含数据的节点，数据也会随之消失。