У меня есть кластер EKS с одним рабочим узлом Linux, который может быть создан в любой зоне доступности в регионе. Мне нужно использовать постоянный объем хранилища, чтобы мои данные не были потеряны в случае смерти узла. Стоит упомянуть, что я говорю о данных RabbitMQ.
Я пробовал использовать том EBS, но у него есть жесткое ограничение, в котором он привязан к одной зоне доступности. В случае, если узел умирает, а затем создается в другой зоне доступности, не удается смонтировать том EBS.
Пока у меня есть следующие идеи:
Подключите один том EBS к рабочему узлу. Когда рабочий узел перезапускается в другой зоне доступности, создайте Снимок EBSи используйте его для создания нового тома EBS в правильной зоне доступности. Новый экземпляр узла смонтирует новый том EBS.
Создайте рабочий узел для каждой зоны доступности с выделенным томом EBS. RabbitMQ может автоматически дублировать данные на томах EBS. Это устраняет необходимость в использовании моментальных снимков EBS, как предлагается в решении 1.
Иметь один том EFS, который можно подключить к нескольким узлам во всех зонах доступности.
Кроме того, я наткнулся на эта почта который объясняет более сложные подходы к моей проблеме:
Другой вариант, который я бы порекомендовал для Kubernetes 1.10 / 1.11, - это контролировать, где создаются ваши тома и где запланированы ваши поды:
- Чтобы создать тома в заранее определенных зонах, вы можете создать собственные объекты StorageClass для каждой зоны, которую хотите использовать (см. https://kubernetes.io/docs/concepts/storage/storage-classes/#aws-ebs).
- Чтобы указать зоны, в которых запланированы ваши поды с PV, вы можете использовать affinity или nodeSelector: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
- Если вы используете автоматическое масштабирование кластера, имейте в виду, что вам, вероятно, понадобятся отдельные группы автоматического масштабирования для каждой зоны доступности (см. kubernetes / autoscaler # 501Вы также можете прочитать об этом здесь: кубернетес / кубернетес # 34583
Вы можете помочь мне сравнить эти подходы? Например, с точки зрения масштабируемости, рентабельности, ремонтопригодности ... Или, может быть, вы можете придумать лучший вариант?