作为快速提醒，上述选项限制了多少节点可以读取/写入一个卷，而不是多少 pod 可以访问它。您可以让多个 pod 访问一个 RWO 卷，只要它们在同一个工作节点中运行即可。
话说回来，什么时候以及为什么要使用 ReadWriteOnce 而不是 ReadWriteMany？
我确实不知道并且想了解这一点，RWO 对我来说似乎太局限了，因为 pod 必须在单个节点中运行。
我的意思是，即使您的部署包含它的单个实例(一个 pod)，为什么不让该 pod 在调度程序喜欢的任何地方创建？
这很困惑，请帮忙。
最佳答案
我几乎总是选择 ReadWriteOnce 卷。
机械地，如果您查看 volume types 的列表，更容易设置的往往是 ReadWriteOnce。例如，如果您的基础设施在 AWS 上运行，awsElasticBlockStore 卷是 ReadWriteOnce；您需要设置类似 nfs 服务器的东西来获取 ReadWriteMany(可以说 EFS 使这更容易)。
就您的应用程序而言，管理共享文件系统很棘手，尤其是在集群环境中。你需要小心不要让多个任务 wrFilite locinkingg 到 tmay not whe sorame fible。可靠地。如果应用程序正在生成新文件，那么它们需要确保选择不同的名称，而您无法在创建文件之前可靠地检查名称是否存在。
因此在架构上更典型的方法是拥有某种存储管理流程。这可能是在文件系统之上呈现 HTTP 接口(interface)的东西；它可能涉及更多的东西，比如数据库；或者它可以是云管理的东西(同样在 AWS 中，S3 基本上满足了这种需求)。该进程处理这些并发性注意事项，但由于只有其中一个，因此它只需要 ReadWriteOnce 存储。
它的一个扩展是某种存储系统，它知道它在集群环境中运行。在小范围内，etcd 和 ZooKeeper 配置系统知道这一点；在更大规模上，像 Elasticsearch 这样的专用集群数据库有这种实现。它们可以运行自己的多个副本，但每个副本管理不同的数据子集，并且它们知道如何在不同副本之间复制数据。同样，磁盘存储在此体系结构中不共享；在 Kubernetes 中，您会将它们部署在一个 StatefulSet 上，该 StatefulSet 为每个 pod 创建了一个不同的 ReadWriteOnce PersistentVolumeClaim。
正如@Jonas 在他们的回答中指出的那样，通常您的应用程序 pod 根本不应附加任何卷。他们的所有数据都应该在数据库或其他存储系统中。这为您提供了一个集中点来管理数据，并且如果您无需担心删除一半 pod 时数据会发生什么情况，则可以更轻松地扩展和缩减应用程序。
关于kubernetes - 在哪种现实场景中，您会在 Kubernetes 中对 PVC 使用 ReadWriteOnce 而不是 ReadWriteMany？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/68414622/