首先,你是否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。这是学习基本思想的好方法ReadWriteMany
Kubernetes 存储将服务于大多数用例,并且是最容易实现的。在您掌握了多服务持久性的应用知识后,您就可以做出更明智的决策来使用功能更丰富的产品,而这通常需要更多的工作来实施。
设置 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