Я разрабатываю приложение, которое поставляется как облачный сервис, то есть есть n экземпляры этого приложения, и каждый из них полностью отделен друг от друга, и каждый из этих отдельных клонов хранит данные в своем собственном pgsql database.
В настоящее время существует один единственный сервер базы данных, и я вручную настроил образы докеров этого приложения и подключил этот образ к вновь созданной базе данных на общем сервере баз данных. Этот процесс отнимает много времени и усилий, поэтому я хотел бы автоматизировать его с помощью Kubernetes.
Я разработал структуру с одним главным сервером, который будет организовывать и автоматизировать создание узлов, но один из многих возникших вопросов: как лучше всего справиться с хранением данных такой архитектуры?
Лучше ли размещать один сервер базы данных на стручок, или я должен создать один место хранения единица для всего узел и сделать стручки подключиться к нему? Подходит ли то, чего я хотел бы достичь, даже для Kubernetes? То есть автоматизировать развертывание одного докер изображение, которое будет реплицировано как полностью отдельные экземпляры, каждый со своей собственной базой данных.
Если у вас действительно так много отдельных экземпляров приложения, настройте отдельный экземпляр базы данных для него в каждом Pod может быть довольно утомительной задачей. Конечно те Pods не должен быть просто голым Pods но ими должен управлять какой-то контроллер, например Deployment или Statefulset (что больше подходит для приложений с отслеживанием состояния, таких как базы данных). Независимо от того, составляет ли количество создаваемых и управляемых им реплик только одну, вы должны использовать контроллер, поскольку он будет обрабатывать Pod жизненный цикл для вас.
Размещение обоих применение и база данных в единственном Pod не рекомендуемый подход. В соответствии с архитектура микросервисов подход, все элементы вашего приложения, такие как его внешний интерфейс часть, внутренний API и база данных не должны быть тесно связаны, т.е. размещать все эти элементы в одном Pod определенно не рекомендуемый подход. Это все еще возможно и технически осуществимо, но имеет множество недостатков.
Гораздо лучше развернуть каждый экземпляр вашего приложения как отдельный Deployment если они должны быть полностью независимыми друг от друга, а не запускаться как набор Pods управляется одним Deployment. Каждый из тех Pods может подключаться к экземпляру базы данных, управляемой отдельным StatefulSet.
Если у вас уже настроен сервер базы данных, он также может использоваться вашим Pods. Это все еще приемлемый подход, поскольку контейнеры, как правило, не лучший выбор для запуска. приложения с отслеживанием состояния и во многих случаях может быть даже лучше запускать их на голом железе или виртуальных машинах.
Если ваш сервер базы данных имеет полное доменное имя (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, а не через прокси или пересылку. Если позже вы решите переместить свою базу данных в кластер, вы можете запустить ее модули, добавить соответствующие селекторы или конечные точки и изменить параметры Сервиса.type.
Тогда вы можете использовать свой Service name (при работе с одним пространством имен) в вашем приложении для подключения к вашей базе данных. Вот вы можете увидеть как внешний интерфейс часть приложения может быть связана с его бэкэнд. Если ваше приложение поддерживает файл конфигурации, в котором вы можете указать URL-адрес базы данных, вы можете передать его на свой Pod через ConfigMap, без необходимости изменять код и перестраивать образ докера.
Надеюсь, это поможет и немного проясняет доступные варианты.