首先，你是否really需要多个读者/作者？
根据我对 Kubernetes/微服务架构 (MSA) 的经验，这个问题通常与你的设计模式更相关。 MSA 的基本设计模式之一是服务的正确封装，其中包括每个服务拥有的数据。
与 OOP 非常相似，您的服务应该照顾与其关注领域相关的数据，并且应该允许其他服务通过接口访问这些数据。该接口可以是 API、直接处理或通过代理服务处理的消息，或者使用协议缓冲区和 gRPC。一般来说，对数据的多服务访问是一种反模式，类似于 OOP 和大多数编程语言中的全局变量。
例如，如果您希望写入日志，则应该有一个日志服务，每个服务都可以使用其需要记录的相关数据来调用该服务。直接写入共享磁盘意味着，如果您更改日志目录结构，或者决定添加额外的功能（例如针对某些类型的错误发送电子邮件），则需要更新每个容器。
在大多数情况下，您应该在使用文件系统之前使用某种形式的最小接口，以避免意外的副作用海仑定律您在使用文件系统时所接触到的。如果服务之间没有适当的接口/契约，您构建可维护和有弹性的服务的能力就会大大降低。
好的，您的情况最好使用文件系统来解决。有多种选择...
显然，有时可以处理多个并发写入器的文件系统可以提供比更“传统”MSA 形式的通信更优越的解决方案。 Kubernetes 支持大量卷类型，可以找到here。虽然此列表相当长，但其中许多卷类型不支持多个写入器（也称为ReadWriteMany在 Kubernetes 中）。
那些支持的卷类型ReadWriteMany可以找到这张桌子在撰写本文时，这是 Azure File、Ceph、Glusterfs、Quobyte、NFS 和 Portworx Volume。
还有一些运营商，例如流行的rook.io它们功能强大并提供了一些很棒的功能，但是当您只想要一个简单的解决方案并继续前进时，此类系统的学习曲线可能会很困难。
最简单的方法。
根据我的经验，最好的初始选择是 NFS。这是学习基本思想的好方法ReadWriteManyKubernetes 存储将服务于大多数用例，并且是最容易实现的。在您掌握了多服务持久性的应用知识后，您就可以做出更明智的决策来使用功能更丰富的产品，而这通常需要更多的工作来实施。
设置 NFS 的细节根据集群的运行方式和位置以及 NFS 服务的细节而有所不同，我之前写过两篇关于如何设置 NFS 的文章本地集群并使用 AWS NFS 等效项EKS 集群上的 EFS。这两篇文章很好地对比了如何根据您的特定情况使用不同的实现。
举个最低限度的例子，您首先需要一个 NFS 服务。如果您想要进行快速测试或者您的 SLO 要求较低，请执行以下操作这篇 DO 文章是在 Ubuntu 上设置 NFS 的快速入门指南。如果您现有的 NAS 提供 NFS 并且可以从集群访问，那么这也可以。
一旦有了 NFS 服务，您就可以创建类似于以下内容的持久卷：
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-name
spec:
capacity:
storage: 1Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
nfs:
server: 255.0.255.0 # IP address of your NFS service
path: "/desired/path/in/nfs"
这里需要注意的是，您的节点需要安装二进制文件才能使用 NFS，我在我的文章中详细讨论了这一点本地集群文章。这也是你的原因need在 EKS 上运行时使用 EFS，因为您的节点无法连接到 NFS。
设置持久卷后，使用它就像使用任何其他卷一样简单。
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-name
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: p-name
volumeMounts:
- mountPath: /data
name: v-name
volumes:
- name: v-name
persistentVolumeClaim:
claimName: pvc-name
