Каковы преимущества / недостатки развертывания моей базы данных и приложения в отдельных контейнерах в одном модуле?

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

Немного предыстории: приложение находится за прокси-сервером Nginx. Все запросы проходят от прокси к веб-серверу. Веб-сервер - единственное, что имеет доступ к базе данных (только для чтения).

Архитектура 1:

Под №1 - только контейнер базы данных

Под № 2 - только контейнер приложения

Архитектура 2:

Модуль №1 - Контейнер базы данных и контейнер приложения

Из моих исследований я нашел комментарии, рекомендующие Архитектуру 1 по причинам масштабирования. https://linchpiner.github.io/k8s-multi-container-pods.html

Кто-нибудь знает, какой из этих подходов лучше подходит для моей ситуации?


person havak5    schedule 10.08.2018    source источник


Ответы (2)


Возможность независимого масштабирования приложения и базы данных была бы ключевой причиной их разделения. Масштабирование с высокой нагрузкой (или сильно изменяющейся нагрузкой) требует надежной архитектуры, и то, что считается «высокой нагрузкой», будет зависеть от вашего приложения. Например, если база данных и приложение находятся в разных модулях, теоретически вы можете запустить несколько реплик приложения (то есть несколько модулей) и (если хотите) только одну реплику базы данных, на которую указывают все экземпляры приложения. . И вы можете настроить маршрутизацию контроллера входящего трафика nginx к экземплярам приложения и балансировку нагрузки между ними.

Запуск нескольких реплик может дать вам возможность увеличивать и уменьшать масштаб в ответ на загрузку (см., Например, HorizontalPodAutoscaler, но вы также можете масштабировать вручную). Он обеспечивает определенный уровень отказоустойчивости, поскольку один экземпляр может быть перегружен и перестать отвечать (или просто выйти из строя), не затрагивая другие (а отказавший модуль также может быть автоматически перезапущен Kubernetes).

Потенциальная загвоздка, на которую следует обратить внимание при запуске нескольких реплик вашего приложения, по крайней мере, если это существующее приложение, которое вы переносите на kubernetes, заключается в том, что ваше приложение должно быть написано без сохранения состояния для поддержки этого. Предположительно, ваш db доступен только для чтения, что означает, что это не проблема на уровне данных. Возможно, вы могли бы также запустить несколько реплик db и использовать службу, чтобы экземпляры вашего приложения могли общаться с ними. Но вам также нужно подумать о сохранении состояния в приложении, например. На основе токена аутентификации и могут ли разные экземпляры проверять токен без необходимости нового входа в систему?

Не обязательно помещать два контейнера в одну капсулу. В вашем случае вы все равно можете получить некоторые преимущества масштабирования, как если бы ваша база данных была доступна только для чтения, тогда, по-видимому, экземпляры не могут рассинхронизироваться. Но тогда вы можете масштабировать их только вместе, и точно так же каждая пара потерпит неудачу вместе.

person Ryan Dawson    schedule 10.08.2018
comment
Имеется ли какая-либо причина против размещения контейнеров в одном модуле для приложения без сохранения состояния? Используя приведенный выше пример, если один из моих модулей с двумя контейнерами выйдет из строя, Kubernetes просто перезапустит его. Масштабированием можно управлять, создавая больше экземпляров модуля. Насколько я понимаю, Kubernetes будет обрабатывать входящие запросы маршрутизации равномерно между модулями. - person havak5; 10.08.2018
comment
Насколько я понимаю, это должно быть нормально. - person Ryan Dawson; 10.08.2018

По той же причине вы не размещаете веб-сервер и БД на одном компьютере или виртуальной машине.

Две ключевые причины - это аспекты безопасности и производительности.

Ваш Интернет может быть общедоступным, но ваша БД - нет. Вы должны стремиться максимально уменьшить поверхность атаки.

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

В конце концов, если вас не волнуют эти соображения, их проще поддерживать в одном контейнере / модуле.

HTH

person Sam    schedule 10.08.2018