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

чтобы это сделать вне пода, оба контейнера должны быть запущены с --net=host

нагуглил про kube-dns, там 3 контейнера: один с хелфчеками, один мониторит какие-то изменения, один добавляет кеширование.. ну, допустим.. а если нагрузка будет расти , как это будет масштабироваться? появится клон этого пода (все три контейнера будут продублированы)?

да

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

да

а ресурсы в Kubernetes выделяются именно на pod, а не на контейнер, верно?

нет

лимиты можно и поконтейнерно развешивать

понял, то есть оба варианта

я правильно понимаю, что в случае с веб-проектом статика (плюс прокси в виде nginx), код (uwsgi, Python, Django) и СУБД (PostgreSQL) нет смысла запихивать в 1 pod?

конечно

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

и для каждого контейнера выделить какие-то диапазоны портов на нём

постгрес вообще имеет смысл петсетом делать

он же stateful

не очень понял фразу, это про волаймы?

да, у меня контейнер с PostgreSQL использует волайм, где лежит база

аналогичный волайм для медиа-файлов (к нему доступ к прокси-nginx и контейнера с кодом)

волайм?

data volume

а

просто папка на сервере

за пределами контейнеров

то есть в одном база, в другом медиа-файлы (например, пользователи загружают из админки)

и вот, сразу вопрос - если запускать это на 3 серверах, как правильно тут сделать с базой?

а если под на другой сервер переедет?

в идеале - сделать отказоустойчивый сервис

чтобы выключение любых двух серверов не сломал проект

тут нужна репликация СУБД между контейнерами на разных серверах?

это самый правильный способ?

а чем тебе это поможет с постгресом?

мультимастера там еще не придумали

ну, если мастер выключится, по идее ведь друг должен стать мастером

как?

ну, увидит, что главный мастер потух

для этого надо явно сделать промоут

какой вообще рекомендованный способ?

ты когда-нибудь без контейнеров такое делал?

нет, но гайды в инете есть же

ясно

есть ещё вариант сделать какую-то единую файловую систему между тремя серверами и туда поставить postgresql

но многие очень критикуют такой вариант

ты слишком много теоретизируешь при недостаточной базе

ешь слона по кусочкам

так я и спрашиваю, какой вариант правильный

допустим, у меня 3 одинаковых контейнера на разных серверах, всем нужна база

как правильнее всего это организовать чтобы была отказоустойчивость

не получится по паре гайдов из интернета сделать отказоустойчивый кластер из неизвестных тебе технологий

почему неизвестных, мне не ясны лишь некоторые моменты

есть вариант через master-slave, есть, например, такой плагин к Django https://github.com/yandex/django_replicated

но, может, есть и проще способы

wat?

этот плагин позволяет джанге писать в мастера, а читать сразу из нескольких инстансов

например, как я писал выше, какая-то сетевая файловая система на базе дисков всех трёх серверов и там этот data volume с базой

при чем тут отказоустойчивость-то?

смерть мастера все-равно все убъет

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

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

если nginx на одном из них не отвечает - запрос уйдёт на другой сервер, где будет свой nginx, свой код и своя субд, к которой код и полезет с запросом

это если запросы на чтение

а про запросы на запись я не знаю как лучше сделать, наверное, тут надо погуглить и подумать про разные варианты...

никак

ну, 1 из вариантов - писать сразу во все 3 базы

если 1 из них недоступна - возвращать 500

другой вариант - выбрать мастер и писать в него, если мастер недоступен - возвращать 500

какие-то варианты всё равно есть

ERROR: S client not available

ну а дальше-то что делать?

третий вариант - сделать сетевую файловую систему и туда поставить контейнер с базой

вот у тебя выбранный мастер сломался

и?

тут или 500 (ждём, пока он починится) или переключаем слейв в мастер

и потом после восстановления мастера синхронизируем его

а остальных слейвов пересинхронизируем с новым мастером

и старый мастер тоже становится слейвом

где тут про отказоустойчивость-то?

это же часы ручной работы

эту синхронизацию нельзя автоматизировать?

как те же хостеры, например, делают?

какие хостеры?

ну, какие-нибудь облачные

хероку там какой-нибудь

я работал в подобном "хостере"

там круглые сутки сидит грядка S2L'ей и смотрит в заббикс

https://www.heroku.com/

мм

дада, я знаю, что такое хероку

но у них не три сервера

и они могут себе позволить круглосуточный мониторинг инфраструктуры

а вариант с объединить SSD в сетевую ФС (Ceph какой-нибудь) и там запускать контейнер с PostgreSQL, 1 на облако?

он нормальный?

а в чем тогда смысл вообще контейнеризировать постгрес?

ну, просто для удобства

доставки

и еще помимо устойчивости многих интересует перфоманс и вот тут-то все начинают советовать так не делать

не городить сетевых файловых систем и вот этого всего

производительность сильно падает даже если NVMe диски?

да хоть в памяти держи

ты в сеть упрешься