我有一个带有一个 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/autoscaler#501）您还可以在此处阅读有关此内容的一些内容：kubernetes/kubernetes#34583
您能帮我比较这些方法吗？比如在可扩展性、成本效率、可维护性方面……或者也许你能想到更好的？