如何在库伯内特斯豆荚之间共享存储？

Question

我正在评估Kubernetes作为我们新应用程序的平台。现在看来，这一切都非常令人兴奋！但是，我遇到了一个问题：我在GCE上托管集群，需要某种机制在两个POD（持续集成服务器和应用服务器）之间共享存储。对库伯内特斯来说，最好的方法是什么？所有的卷类型似乎都不适合我的需要，因为如果一个pod需要写入磁盘，GCE磁盘就不能共享。NFS将是完美的，但似乎需要kubernetes集群的特殊构建选项？

编辑：共享存储似乎是我在使用Kubernetes时多次遇到的问题。有多种使用情形，我只想拥有一个卷并将其连接到多个pod（具有写访问权限）。我只能假设这是一个常见的用例，不是吗？

EDIT2：例如，本页描述了如何设置一个Elasticsearch集群，但是用持久存储连接它是不可能的（如这里所述），这使得它毫无意义：（

Answer 1

NFS是一个内置卷插件，支持多个pod写入程序。没有特殊的构建选项可以让NFS在Kube中工作。

我在Kubernetes的Red Hat工作，主要关注存储。

Answer 2

首先呢。库伯内特斯没有在主机之间共享存储的集成功能。下面有几个选项。但是首先，如果您已经设置了一些卷，如何共享存储。

要在多个Pod之间共享一个卷，您需要创建一个具有访问模式的PVC ReadWrite很多

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
    name: my-pvc
spec:
    accessModes:
      - ReadWriteMany
    storageClassName: myvolume
    resources:
        requests:
            storage: 1Gi

之后，您可以将其装载到多个吊舱：

apiVersion: v1
kind: Pod
metadata:
  name: myapp1
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app1
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp2
spec:
  containers:
...
      volumeMounts:
        - mountPath: /data
          name: data
          subPath: app2
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: 'my-pvc'

当然，持久卷必须通过网络访问。否则，您需要确保所有Pod都被调度到具有该卷的节点。

有几种卷类型适用于此，并且不与任何云提供商绑定：

• NFS

当然，要使用一个卷，首先需要拥有它。也就是说，如果您想要使用NFS，您需要在K8s集群中的所有节点上设置NFS。如果您想使用Ceph，则需要设置Ceph集群等等。

唯一支持库伯内特斯开箱即用的卷类型是Portworks。有关于如何在GKE中设置它的说明。

要在K8s中设置Ceph集群，有一个名为Rook的项目正在开发中。

但是，如果您只希望一个节点中的文件夹在另一个节点中可用，那么这就太过分了。在这种情况下，只需设置NFS服务器。它不会比配置其他卷类型更难，而且会消耗更少的cpu/内存/磁盘资源。

Answer 3

根据我对Kubernetes/micro service architecture（MSA）的经验，这个问题通常与您的设计模式更相关。MSA的基本设计模式之一是服务的适当封装，这包括每个服务拥有的数据。

与OOP的方式大致相同，您的服务应该关注与其关注领域相关的数据，并且应该允许通过接口访问其他服务的数据。该接口可以是API、直接或通过brokage服务处理的消息，或使用协议缓冲区和gRPC。通常，对数据的多服务访问是一种反模式，类似于OOP和大多数编程语言中的全局变量。

例如，如果您希望在何处写入日志，那么您应该拥有一个日志服务，每个服务都可以使用需要记录的相关数据调用该服务。直接写入共享磁盘意味着，如果您更改日志目录结构，或者决定添加额外功能（如针对某些类型的错误发送电子邮件），则需要更新每个容器。

在大多数情况下，在使用文件系统之前，您应该使用某种形式的最小接口，避免使用文件系统时暴露于Hyrum定律的意外副作用。如果服务之间没有适当的接口/契约，则会严重降低构建可维护和弹性服务的能力。

显然，有时，能够处理多个并发编写器的文件系统提供了优于“传统”MSA通信形式的解决方案。Kubernetes支持大量的卷类型，可以在这里找到。虽然此列表很长，但其中许多卷类型不支持多个写入程序（在Kubernetes中也称为ReadWriteMany）。

可以在此表中找到那些支持ReadWrite很多的卷类型，在编写时，这些卷类型是AzureFile、CephFS、Glusterfs、Quobyte、NFS和PortworxVolume。

还有一些运营商，比如流行的rook。io功能强大，并提供了一些强大的功能，但当您只需要一个简单的解决方案并继续前进时，这类系统的学习曲线可能会很困难。

根据我的经验，最好的初始选择是NFS。这是一个很好的学习有关ReadWriteManyKubernetes存储的基本思想的方法，它将服务于大多数用例，并且是最容易实现的。在您建立了多服务持久性的实用知识之后，您就可以做出更明智的决定，使用更多功能丰富的产品，这通常需要更多的工作来实现。

根据群集的运行方式和位置以及NFS服务的具体情况，设置NFS的细节有所不同，我之前写了两篇文章，介绍如何为本地群集设置NFS，以及在EKS群集上使用AWS NFS等效的EFS。这两篇文章给出了一个很好的对比，说明了如何根据您的特定情况实现不同的实现。

举个简单的例子，您首先需要一个NFS服务。如果你想做一个快速测试，或者你的SLO要求很低，下面这篇文章是在Ubuntu上设置NFS的快速入门。如果您有一个提供NFS的现有NAS，并且可以从您的群集访问它，那么这也可以工作。

拥有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，我已经在我的on-prem集群文章中详细讨论了这一点。这也是在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