在哪个真实世界场景中，您会使用 ReadWriteOnce 而不是 ReadWriteMany 作为 Kubernetes 中的 PVC？

如何解决在哪个真实世界场景中，您会使用 ReadWriteOnce 而不是 ReadWriteMany 作为 Kubernetes 中的 PVC？

提醒一下，上述选项限制了可以读取/写入卷的节点数，而不是可以访问卷的 Pod 数。您可以让多个 Pod 访问一个 RWO 卷，只要它们在同一个工作节点中运行即可。

话虽如此，您何时以及为什么要使用 ReadWriteOnce 而不是 ReadWriteMany？

我确实不知道也想了解这一点，RWO 对我来说似乎太局限了，因为 Pod 必须在单个节点中运行。

我的意思是，即使您的部署包含它的单个实例（一个 Pod），您为什么不让调度程序随意创建该 Pod？

这令人困惑，请帮忙。

解决方法

何时以及为什么要使用 ReadWriteOnce 而不是 ReadWriteMany？

首先，您需要考虑哪些访问模式可用于您正在使用的存储系统。查看 access modes 文档时，您很快就会发现只有 ReadWriteOnce 是广泛可用的，因此在许多情况下，您没有其他选择。

但这也归结为架构，在许多情况下，在 Kubernetes 上，您正在设计分布式系统，并且在许多情况下，您希望每个实例都拥有自己的数据 - 使用 无共享 架构。考虑到这一点，在许多情况下，ReadWriteOnce 足以满足您的需求。

我的意思是，即使您的部署包含它的单个实例（一个 Pod），您为什么不让调度程序随意创建该 Pod？

这里有两种情况：

• 无状态应用 - 这些通常部署没有持久卷 - 因此无论如何都可以安排到调度程序喜欢的任何地方。

• 有状态的应用程序 - 例如Redis 案例或分布式数据库 - 这些对位置更敏感 - 但您也需要这种控制来理解和控制故障域。对于这些应用程序，如果它们使用卷 - 它们通常在设计时考虑了无共享架构，并且设计为每个实例都希望控制自己的卷 - 因此 ReadWriteOnce 访问模式是你需要什么。

,

我几乎总是选择 ReadWriteOnce 卷。

从机制上看，如果您查看 volume types 的列表，更容易设置的往往是 ReadWriteOnce。例如，如果您的基础设施在 AWS 上运行，则 awsElasticBlockStore 卷为 ReadWriteOnce；您需要设置类似 nfs 服务器之类的东西来获取 ReadWriteMany（可以说 EFS 使这更容易）。

就您的应用程序而言，管理共享文件系统很棘手，尤其是在集群环境中。你需要小心不要有多个任务 wrFilite locinkingg 到 tmay not where sorame fikle。可靠。如果应用程序正在生成新文件，那么它们需要确保选择不同的名称，并且您无法在创建文件之前可靠地检查名称是否存在。

因此在架构上更典型的方法是拥有某种存储管理流程。这可能是在文件系统之上呈现 HTTP 接口的东西；它可能是更复杂的东西，比如数据库；或者它可以是云管理的东西（同样在 AWS 中，S3 基本上满足了这种需求）。该进程处理这些并发考虑，但由于只有其中之一，因此它只需要 ReadWriteOnce 存储。

这种扩展是某种存储系统，它知道它在集群环境中运行。在小范围内，etcd 和 ZooKeeper 配置系统知道这一点；在更大规模的情况下，像 Elasticsearch 这样的专用集群数据库就有这种实现。它们可以运行自身的多个副本，但每个副本管理不同的数据子集，并且它们知道如何在不同副本之间复制数据。同样，磁盘存储在此架构中不共享；在 Kubernetes 中，您将这些部署在 StatefulSet 上，该 StatefulSet 为每个 pod 创建了一个不同的 ReadWriteOnce PersistentVolumeClaim。

正如@Jonas 在他们的回答中指出的那样，通常您的应用程序 pod 根本不应该附加任何卷。他们的所有数据都应该在数据库或其他一些存储系统中。这为您提供了一个管理数据的集中点，如果您无需担心删除一半 Pod 时数据会发生什么情况，则可以更轻松地扩展和缩减应用程序。