Вопросы Теги

Kubernetes, модули с уникальным сервером базы данных vs один общий сервер базы данных

Я разрабатываю приложение, которое поставляется как облачная служба, то есть существует n экземпляров этого приложения, и каждый из них полностью отделен друг от друга, и каждый из этих отдельных клонов хранит данные в своем собственном pgsql. база данных .

В настоящее время существует одна единственная база данных se, и я вручную настроил образы докеров этого приложения и подключил этот образ к вновь созданной базе данных на общем сервере баз данных. Этот процесс отнимает много времени и усилий, поэтому я хотел бы автоматизировать его с помощью Kubernetes .

Я разработал структуру с одним главным сервером, который будет организовывать и автоматизировать создание узлов, но с одним из многих возникших вопросов - как лучше всего справиться с хранением данных такой архитектуры?

Что лучше: разместить один сервер базы данных на каждый pod , или я должен создать одно хранилище блок для всего узла и подключить к нему поды ? Подходит ли то, чего я хотел бы достичь, даже для Kubernetes? Это сделано для автоматизации развертывания одного образа докера , который будет реплицирован как полностью отдельные экземпляры, каждый со своей собственной базой данных.

0
задан 25 February 2020 в 16:39
1 ответ

Если у вас действительно так много отдельных экземпляров приложения, настройка отдельного экземпляра базы данных для него в каждом Pod может быть довольно утомительное занятие. Конечно, эти Pod не должны быть просто пустыми Pods , но они должны управляться каким-либо контроллером, например Deployment или Statefulset (который больше подходит для приложений с отслеживанием состояния, таких как базы данных). Независимо от того, равно ли количество создаваемых им реплик и управляемых ими реплик, вы должны использовать контроллер, поскольку он будет обрабатывать жизненный цикл Pod за вас.

Размещение как приложения , так и база данных в одном Pod не рекомендуется. Согласно подходу архитектуры микросервисов , все элементы вашего приложения, такие как его интерфейсная часть , внутренняя часть API и база данных не должны быть тесно связаны, то есть размещение всех этих элементов в одном Pod определенно не рекомендуется. Это все еще возможно и технически осуществимо, но имеет много недостатков.

Гораздо лучше развернуть каждый экземпляр вашего приложения как отдельное развертывание , если они должны быть полностью независимыми друг от друга, а не запускаться как единое целое. набор модулей , управляемых одним развертыванием . Каждый из этих модулей может подключаться к экземпляру базы данных, управляемому отдельным StatefulSet .

Когда у вас уже настроен сервер базы данных, он также может использоваться вашим Стручки . Это все еще приемлемый подход, поскольку контейнеры, как правило, не лучший выбор для запуска приложений с отслеживанием состояния , и во многих случаях может быть даже лучше запускать их на «голом железе» или виртуальных машинах.

Если на вашем сервере базы данных есть свои приложения. полностью уточненное доменное имя (FQDN), вы можете просто определить тип ExternalName Service , указывающий на это доменное имя: 

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

При поиске хоста my-service.prod.svc.cluster .local , Служба DNS кластера возвращает запись CNAME со значением my.database.example.com . Доступ к my-service работает в том же так же, как и другие Сервисы, но с той важной разницей, что перенаправление происходит на уровне DNS, а не через прокси или пересылку. Если вы позже решите переместить свою базу данных в кластер, вы может запускать свои поды, добавлять соответствующие селекторы или конечные точки и изменять тип службы .

Затем вы можете использовать свое имя службы (при работе с одним пространством имен) в своем приложении для подключения к своей базе данных. Здесь вы можете увидеть, как интерфейсная часть приложения может быть связана с его серверной частью . Если ваше приложение поддерживает файл конфигурации, в котором вы можете указать URL-адрес базы данных, вы можете передать его в свой Pod через ConfigMap , без необходимости изменять код и перестраивать образ докера.

] Надеюсь, это поможет и немного проясняет доступные варианты.

0
ответ дан 26 February 2020 в 00:41

Теги

Похожие вопросы