具有多个可用区的 EKS 集群中的持久存储

Question

我有一个带有一个 Linux 工作节点的 EKS 集群，它可以在一个区域内的任何可用区中实例化。我需要使用持久存储卷，这样即使节点死亡，我的数据也不会丢失。值得一提的是，我说的是RabbitMQ数据。

我尝试过使用 EBS 卷，但它有一个硬限制，即它绑定到单个可用区。如果节点死亡，然后实例化到不同的可用区，则无法挂载 EBS 卷。

到目前为止我有以下想法：

1. 将单个 EBS 卷附加到工作节点。当工作节点在不同的可用区中重新启动时，创建EBS 快照，并使用它在正确的可用区中创建新的 EBS 卷。新的节点实例将挂载新的 EBS 卷。

2. 每个可用区都有一个工作节点，并有一个专用的 EBS 卷。RabbitMQ 可以自动跨 EBS 卷复制数据。这样就无需使用 EBS 快照，如解决方案 1 中建议的那样。

3. 拥有一个可连接到所有可用区的多个节点的 EFS 卷。

此外，我发现这篇文章解释了解决我的问题的更复杂的方法：

我为 Kubernetes 1.10/1.11 推荐的另一个选项是控制卷的创建位置以及 pod 的调度位置：

• 要在预先确定的区域中创建卷，您可以为要使用的每个区域创建自定义 StorageClass 对象（请参阅https://kubernetes.io/docs/concepts/storage/storage-classes/#aws-ebs）。
• 要指定调度具有 PV 的 pod 的区域，您可以使用affinity 或 nodeSelector： https: //kubernetes.io/docs/concepts/configuration/assign-pod-node/
• 如果您使用集群自动缩放，请记住，您可能需要为每个可用区单独的自动缩放组（请参阅kubernetes/autoscaler#501）您还可以在此处阅读有关此内容的一些内容：kubernetes/kubernetes#34583

您能帮我比较这些方法吗？比如在可扩展性、成本效率、可维护性方面……或者也许你能想到更好的？

Answer 1

这个问题的解决方案是使用 EFS 而不是 EBS，这将确保当节点死亡时，新的 Pod 能够连接到同一存储。

EFS 可跨多个可用区进行复制，其成本是 EBS 的 3 倍。

您可能需要考虑使用托管消息队列服务（如 Kafka 或 Kinesis 等）来考虑更具成本效益的解决方案，并减少管理开销。