问在哪个真实场景中，您会在Kubernetes中使用ReadWriteMany上的ReadWriteOnce作为PVC？

EN

什么时候以及为什么要在ReadWriteMany上使用ReadWriteOnce？

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

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

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

这里有两种情况：

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

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

我几乎总是会选择ReadWriteOnce卷。

机械地说，如果你看一下volume types的列表，更容易设置的往往是ReadWriteOnce。例如，如果您的基础设施在亚马逊网络服务上运行，则awsElasticBlockStore卷为ReadWriteOnce；您需要设置类似于nfs服务器的东西来获取ReadWriteMany (可以说EFS使这一点变得更容易)。

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

因此，从体系结构上讲，更典型的方法是采用某种存储管理流程。这可以是在文件系统之上提供HTTP接口的东西；也可以是更复杂的东西，比如数据库；也可以是云管理的东西(同样在亚马逊网络服务中，S3基本上满足了这种需求)。该进程处理这些并发注意事项，但由于只有一个，因此它只需要ReadWriteOnce存储。

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

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