kubernetes - 在哪种现实场景中，您会在 Kubernetes 中对 PVC 使用 ReadWriteOnce 而不是 ReadWriteMany？

Question

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

话说回来，什么时候以及为什么要使用 ReadWriteOnce 而不是 ReadWriteMany？

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

我的意思是，即使您的部署包含它的单个实例(一个 pod)，为什么不让该 pod 在调度程序喜欢的任何地方创建？

这很困惑，请帮忙。

Answer 1

我几乎总是选择 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 时数据会发生什么情况，则可以更轻松地扩展和缩减应用程序。