Я изучаю набор инструментов Kubernetes, и теперь мой выделенный кластер из 3 узлов запущен и работает.
Следующие шаги - перенос проектов нашей компании в кластер. Поскольку мы используем MongoDB и ElasticSearch и хотим разместить несколько проектов в кластере, я не уверен, как правильно обрабатывать постоянство.
Я буду использовать glusterfs с репликацией, работающей непосредственно на узлах (не в кубернетах), и подключать тома к подам, используя
https://github.com/kubernetes/examples/tree/master/staging/volumes/glusterfs
Стоит ли устанавливать MongoDB как ReplicaSet прямо на узлы а также или беги один Экземпляр MongoDB для каждого проекта внутри соответствующего модуля с использованием glusterfs для реплицированного хранилища и резервного копирования?
В качестве требования потеря одного (рабочего) узла должна позволить запускать потерянные модули на других узлах без потери данных.
Как мне сохранить данные базы данных между несколькими узлами? Даже для репликации (MongoDB ReplicaSet e.q.) требуется постоянное хранилище для каждого модуля.
Я бы рекомендовал использовать специальный оператор для обработки приложений с отслеживанием состояния, таких как базы данных в Kubernetes. Есть много способов прострелить себе ногу при работе с приложениями с отслеживанием состояния.
Взгляните на kubedb.com, у них есть операторы как для ElasticSearch, так и для MongoDB. Пользовательские операторы программно заботятся о репликации, обработке сбоя модуля (например, продвижение нового мастера), масштабировании и т. Д.
Монго -> https://kubedb.com/docs/0.8.0-beta.0/guides/mongodb/overview/
Эластичный поиск -> https://kubedb.com/docs/0.8.0-beta.0/guides/elasticsearch/overview/
Вы, конечно же, должны развернуть промежуточную версию и протестировать ее на соответствие своей рабочей нагрузке, прежде чем рассматривать возможность запуска в производство.
Хорошо, после некоторого исследования я нашел эту статью весьма полезной:
https://portworx.com/ha-mongodb-kubernetes/
Они используют portworx в качестве sds, но gluster также должен работать.
Итак, мое предполагаемое решение - запускать базы данных для каждого проекта в отдельном модуле / контейнере. В нашем кластере из 3 узлов я буду реплицировать том базы данных, но запускать только один экземпляр базы данных за раз. Таким образом, переключение и запуск контейнера db на другом узле не должны быть проблемой.
Когда мы добавляем больше узлов в кластер или приложению требуется больше экземпляров базы данных для лучшего масштабирования, я предоставлю реплицированный том для каждого экземпляра db и подключу базы данных с помощью ReplicaSet.