19

我想在 AWS 上设置一个 PVC，我需要ReadWriteMany作为访问模式。不幸的是，EBS 仅支持ReadWriteOnce.

我怎么能解决这个问题？

  • 我已经看到 AWS EFS 有一个支持ReadWriteMany.
  • 我可以使用节点亲和性来强制所有依赖 EBS 卷的 pod 到单个节点，并保持使用ReadWriteOnce，但这限制了可扩展性。

还有其他方法可以解决这个问题吗？基本上，我需要的是一种以持久方式存储数据的方法，以便在彼此独立的 pod 之间共享数据。

4

3 回答 3

24

在没有自动配置的情况下使用 EFS

EFS 供应商可能是测试版，但 EFS 本身不是。由于 EFS 卷可以通过 NFS 挂载，因此您可以简单地PersistentVolume手动创建一个带有 NFS 卷源的卷源——假设自动配置对您来说不是硬性要求：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-efs-volume
spec:
  capacity:
    storage: 100Gi # Doesn't really matter, as EFS does not enforce it anyway
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  mountOptions:
    - hard
    - nfsvers=4.1
    - rsize=1048576
    - wsize=1048576
    - timeo=600
    - retrans=2
  nfs:
    path: /
    server: fs-XXXXXXXX.efs.eu-central-1.amazonaws.com

然后，您可以使用 a 声明此卷，PersistentVolumeClaim并像往常一样在一个 Pod（或多个 Pod）中使用它。

替代解决方案

如果自动配置对您来说是一项硬性要求，那么您可能会考虑其他解决方案：您可以在集群上推出多个分布式文件系统，在ReadWriteManyKubernetes 和/或 AWS 之上提供存储。例如，您可能会看一下Rook（它基本上是 Ceph 的 Kubernetes 操作符）。它也正式仍处于预发布阶段，但我已经使用它一点并且运行得相当好。还有GlusterFS operator，它似乎已经有一些稳定的版本。

于 2018-07-06T19:20:24.890 回答
8

您可以使用Amazon EFS创建具有ReadWriteMany访问模式的 PersistentVolume。

Amazon EKS于 2019 年 9 月 19 日宣布支持 Amazon EFS CSI 驱动程序，这使得使用标准 Kubernetes 接口为在 AWS 上运行的 EKS 和自我管理的 Kubernetes 集群配置弹性文件存储变得简单。

在 Kubernetes 中运行的应用程序可以使用 EFS 文件系统在横向扩展组中的 pod 之间共享数据，或者与在 Kubernetes 内部或外部运行的其他应用程序共享数据。

EFS 还可以帮助 Kubernetes 应用程序实现高可用性，因为写入 EFS 的所有数据都写入多个 AWS 可用区。如果 Kubernetes pod 终止并重新启动，CSI 驱动程序将重新连接 EFS 文件系统，即使该 pod 在不同的 AWS 可用区中重新启动。

您可以按照EKS-EFS-CSI 用户指南将 Amazon EFS CSI 驱动程序部署到 Amazon EKS 集群，基本上如下所示：

步骤 1：部署 Amazon EFS CSI 驱动程序

kubectl apply -k "github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master"

注意：此命令需要 1.14 或更高版本的 kubectl。

步骤 2：为您的 Amazon EKS 集群创建一个 Amazon EFS 文件系统

步骤 2.1：创建一个允许您的 Amazon EFS 挂载点的入站 NFS 流量的安全组。

步骤 2.2：向您的安全组添加一条规则，以允许来自您的 VPC CIDR 范围的入站 NFS 流量。

步骤 2.3：创建配置了您刚刚创建的安全组的 Amazon EFS 文件系统。

Now you are good to use EFS with ReadWriteMany access mode in your EKS Kubernetes project with the following sample manifest files:

1. efs-storage-class.yaml: Create the storage class

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com

kubectl apply -f efs-storage-class.yaml

2. efs-pv.yaml: Create PersistentVolume

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ftp-efs-pv
spec:
  storageClassName: efs-sc
  persistentVolumeReclaimPolicy: Retain
  capacity:
    storage: 10Gi # Doesn't really matter, as EFS does not enforce it anyway
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-642da695

Note: you need to replace the volumeHandle value with your Amazon EFS file system ID.

3. efs-pvc.yaml: Create PersistentVolumeClaim

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ftp-pv-claim
  labels:
    app: ftp-storage-claim
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: efs-sc

That should be it. You need to refer to the aforementioned official user guide for detailed explanation, where your can also find an example app to verify your setup.

于 2020-01-09T20:07:17.603 回答
0

As you mention EBS volume with affinity & node selector will stop scalability however with EBS only ReadWriteOnce will work.

Sharing my experience, if you are doing many operations on the file system and frequently pushing & fetching files it might could be slow with EFS which can degrade application performance. operation rate on EFS is slow.

However, you can use GlusterFs in back it will be provisioning EBS volume. GlusterFS also support ReadWriteMany and it will be faster compared to EFS as it's block storage (SSD).

于 2020-01-10T04:01:43.660 回答