то есть даже если мне не нужно дублировать субд, допустим, мне всё равно придётся

ну да

или не делать её частью пода

потому что ты неправильно под сформировал

а как правильно?

под - неделимая сущность

но тогда каждый контейнер - отдельный под?

масштабироваться, создаваться, удаляться он будет весь целиком

всегда

тогда чем поды отличаются от контейнеров

Service Discovery

чем апельсины отличаются от ящиков с апельсинами?

вот именно так же поды от контейнеров отличаются

то есть под - это группа одинаковых контейнеров?

не обязательно одинаковых

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

исключение - чтение логов

там нужно будет указывать контейнер внутри пода

а можно пример, когда выгоднее объединять в под пачку неодинаковых контейнеров, чем просто пачка этих контейнеров как отдельных подов?

kube-dns

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

масштабировать можно как угодно

все контейнеры в поде объединены общим локалхостом

это важно

то есть ты в одном контейнере можешь слушать 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 с базой

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