Question

我想在需要apply plugin: 'com.android.application' android { compileSdkVersion 28 buildToolsVersion "28.0.0" defaultConfig { applicationId "com.cormac.splashscreen" minSdkVersion 17 targetSdkVersion 28 versionCode 1 versionName "1.0" testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner" } buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } } dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) implementation 'com.android.support:appcompat-v7:28.0.0-alpha3' implementation 'com.android.support.constraint:constraint-layout:1.1.2' testImplementation 'junit:junit:4.12' androidTestImplementation 'com.android.support.test:runner:1.0.2' androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2' }作为访问模式的AWS上设置PVC。不幸的是，EBS仅支持ReadWriteMany。

我该如何解决？

我已经看到有一个适用于ReadWriteOnce的AWS EFS的beta提供程序，但是如上所述，它仍然是beta，并且其安装看起来有些不稳定。
我可以使用节点亲和力将所有依赖EBS卷的Pod强制为一个节点，并停留在ReadWriteMany上，但这限制了可伸缩性。

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

Answer 1

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

Amazon EKS Announced在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 user guide将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文件系统。

现在，您可以在带有以下示例清单文件的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 ：创建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

注意：您需要用您的Amazon EFS文件系统ID替换volumeHandle值。

3。 efs-pvc.yaml ：创建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

应该的。您需要参考上述official user guide进行详细说明，在这里您还可以找到示例应用来验证您的设置。

Answer 2

使用没有自动配置的EFS

EFS设置程序可以是beta，但EFS本身不是。由于可以通过NFS挂载EFS卷，因此您可以简单地手动创建带有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 operator，它似乎已经有一些稳定的版本。

Answer 3

正如您所提到的，使用affinity和node selector的EBS卷将停止可伸缩性，但是对于EBS，仅ReadWriteOnce才有效。

分享我的经验，如果您在文件系统上执行许多操作并频繁推入和提取文件，使用EFS可能会很慢，这可能会降低应用程序性能。 EFS的运行速度很慢。

但是，您可以在后面使用GlusterFs来配置EBS卷。 GlusterFS还支持ReadWriteMany，由于它是块存储（SSD），因此与EFS相比它会更快。

在AWS上使用ReadWriteMany的Kubernetes PVC

3 个答案:

使用没有自动配置的EFS

替代解决方案