我有一个带有一个 Linux 工作节点的 EKS 集群，该节点可以在区域内的任何可用区域中实例化。我需要使用持久存储卷，这样如果节点死亡，我的数据就不会丢失。值得一提的是，我说的是 RabbitMQ 数据。
我尝试过使用 EBS 卷，但它有一个硬性限制，即它只能绑定到单个可用区。如果节点死亡，然后实例化到不同的可用区，无法挂载 EBS 卷。
到目前为止我有以下想法：
将单个 EBS 卷附加到工作节点。当工作节点在不同的可用区重新启动时，创建一个EBS 快照，并使用它在正确的可用区域中创建新的 EBS 卷。新节点实例将挂载新的 EBS 卷。
每个可用区都有一个工作节点，并配有专用的 EBS 卷。RabbitMQ 可以自动在 EBS 卷之间复制数据。这样就无需使用 EBS 快照，如解决方案 1 中建议的那样。
拥有一个可附加到所有可用区域内的多个节点的单个 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/自动缩放器#501）您还可以在这里阅读一些相关内容：kubernetes/kubernetes#34583
您能帮我比较一下这些方法吗？例如，从可扩展性、成本效益、可维护性等方面来看……或者您能想到一个更好的方法吗？
答案1
解决这个问题的方法是使用 EFS 而不是 EBS，这将确保当一个节点死亡时，新的 pod 将能够连接到相同的存储。
EFS 跨多个可用区域进行复制，其成本是 EBS 的 3 倍。
您可能需要考虑使用托管消息队列服务（如 Kafka 或 Kinesis 等）来减少管理开销，从而实现更具成本效益的解决方案