我想在 AWS 上设置 PVC，我需要ReadWriteMany作为访问模式。不幸的是，EBS 仅支持ReadWriteOnce.
我该如何解决这个问题？
- 我已经看到有一个支持
ReadWriteMany的 AWS EFS 测试版提供商，但如前所述，这仍然是测试版，它的安装看起来有些不稳定。 - 我可以使用节点亲和力将所有依赖 EBS 卷的 Pod 强制到单个节点，并保留
ReadWriteOnce，但这限制了可扩展性。
还有其他方法可以解决这个问题吗？基本上，我需要的是一种以持久方式存储数据的方法，以便在彼此独立的 Pod 之间共享数据。
在不自动预配的情况下使用 EFS
EFS 配置器可能是测试版，但 EFS 本身不是。由于 EFS 卷可以通过 NFS 挂载，因此您只需手动创建具有 NFS 卷源的PersistentVolume-- 假设自动配置不是您的硬性要求：
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
然后，您可以使用PersistentVolumeClaim声明此卷，并像往常一样在 Pod(或多个 Pod(中使用它。
替代解决方案
如果自动配置对您来说是一个硬性要求，您可以考虑其他解决方案： 您可以在集群上推出多个分布式文件系统，这些文件系统在 Kubernetes 和/或 AWS 之上提供ReadWriteMany存储。例如，你可以看看 Rook(它基本上是 Ceph 的 Kubernetes 运算符(。它也正式仍处于预发布阶段，但我已经使用它进行了一些工作，并且运行良好。 还有GlusterFS运算符，它似乎已经有一些稳定的版本。
您可以使用 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 文件系统，即使容器在 不同的 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"
注意：此命令需要 kubectl 的 1.14 或更高版本。
步骤 2：为您的 Amazon EKS 集群创建 Amazon EFS 文件系统
步骤 2.1：创建一个安全组，以允许 Amazon EFS 挂载点的入站 NFS 流量。
步骤 2.2：向安全组添加规则以允许来自 VPC CIDR 范围的入站 NFS 流量。
步骤 2.3：创建使用您刚刚创建的安全组配置的 Amazon EFS 文件系统。
现在，您可以在 EKS Kubernetes 项目中使用带有ReadWriteMany访问模式的 EFS，其中包含以下示例清单文件：
1. efs-storage-class.yaml：创建存储类
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：创建持久卷
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
注意：您需要将 volumeHandle 值替换为您的 Amazon EFS 文件系统 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
应该就是这样了。您需要参考上述官方用户指南以获取详细说明，您还可以在其中找到示例应用程序来验证您的设置。
正如您提到的，具有affinity&node selector的EBS卷将停止可扩展性，但是只有EBS才能ReadWriteOnce工作。
分享我的经验，如果您在文件系统上执行许多操作并频繁推送和获取文件，则可能会很慢EFS这可能会降低应用程序性能。 EFS 上的操作速率很慢。
但是，您可以使用GlusterFs后面预置 EBS 卷。GlusterFS还支持ReadWriteMany，与EFS相比，它会更快，因为它是块存储(SSD(。