А на генте заводится?

Интересно а использует ли кто нибудь OpenBSD? 🤔

Я вот только не понял почему неандертальцы на кубернетесе не хрянят БД в контейнере. В кубернетесе одна из фишек(как создатели считают) что можно иметь стэйтфул контейнеры

В докере небось держишь бд? Нагрузка выше 100 запросов есть?

В докере небось держишь бд? Нагрузка выше 100 запросов есть?

Чтобы хранить базы в кубе, нужно знать куб и докер достаточно хорошо. Только в этом случае ты знаешь что конкретно там может сломаться и как именно ты будешь это чинить. И как правило зная всю состовляющую такие вопросы уже больше не появляются.

Я всё вспоминаю баг с про...ом слоя, и страшно

??

Я вот только не понял почему неандертальцы на кубернетесе не хрянят БД в контейнере. В кубернетесе одна из фишек(как создатели считают) что можно иметь стэйтфул контейнеры

Верхний слой терял при активном использовании диска

Иметь в кубере стейтфулл и плакать каждый раз, когда этот стейт технически пролюблен. Вообщем можно, но в целом мелким иметь базу в кубере - значит иметь трудности с ее оптимизацией, лишний слой багов и прочее. Базы(по крайней мере традиционный sql) проектируются и расчитываются на то, что они близко к железу, и умеют сами с ним работать оптимально. Энтерпрайз отдельно обычно держит железный сервер БД, где отдельные ДБА-люди делают, что умеют лучше всего и чувствуют себя сухо и тепло

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

Гуглоклаудось на генте построена

Так база же на volume лежит, при чем тут слой?

На хромось которая на Генте без портов

А ничего уже 20 лет не менялось. Разве что вместо зон и джейлов завезли докер.

да ладно, БД же начали ложить внутрь виртуальных машин

Иметь в кубере стейтфулл и плакать каждый раз, когда этот стейт технически пролюблен. Вообщем можно, но в целом мелким иметь базу в кубере - значит иметь трудности с ее оптимизацией, лишний слой багов и прочее. Базы(по крайней мере традиционный sql) проектируются и расчитываются на то, что они близко к железу, и умеют сами с ним работать оптимально. Энтерпрайз отдельно обычно держит железный сервер БД, где отдельные ДБА-люди делают, что умеют лучше всего и чувствуют себя сухо и тепло

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

А можно поподробнее про трудности оптимизации базы в контейнере?

В случае бд на железе - тебе оптимизировать только связку собственно БД и железа. В случае БД на докере - тебе оптимизировать и тюнить связку сервер - кубер - контейнер - база, причем каждый слой влияет на каждый. Зачем это делать, если можно этого не делать и вообще сдать отдельные сервера с БД либо выделенным ДБА-людям, либо суппортерам и жить спокойнее?

В случае бд на железе - тебе оптимизировать только связку собственно БД и железа. В случае БД на докере - тебе оптимизировать и тюнить связку сервер - кубер - контейнер - база, причем каждый слой влияет на каждый. Зачем это делать, если можно этого не делать и вообще сдать отдельные сервера с БД либо выделенным ДБА-людям, либо суппортерам и жить спокойнее?

То есть, деталей у вас нет, только рассуждения?

То есть, деталей у вас нет, только рассуждения?

Не, @vrutkovs, головной боли и правда больше в Kubernetes от этого. Если уже отлажена схема работы в команде с БД, с которой работают на отдельном сервере, то почему бы и не продолжить.

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

Практики долго нарабатывать. Инструменты-то легко найти. В опыте и практиках проблемы.

Мне насколько помнится Дмитрий Столяров из фланта ответилина многие вопросы что ложить и когда в кубер а чего делать не стоит.

Сейчас гляну, спасибо

Осторожно, мало реальных примеров там.

Я к вайфаю с третьего раза подключаюсь, философия для меня слишком сложная, вы мне ишшью покажите или истории провалов

Покажите истории успеха нагруженных баз в контейнерах.

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

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

Postgres не такой )))

Покажите истории успеха нагруженных баз в контейнерах.

Так какая практика они последние 4 года админили на железе БД, теперь им нужно переехать. Может им проще этот кластер разбить по приложениям и законтейнеризировать

No u

Я с другой стороны подхожу. Если у тебя нагруженная и высокодоступная БД, то с Kubernetes придётся подумать. Убедиться, что ты полностью понимаешь работу всех накруток, в виде cgroup, namespaces, mounts на уровне Linux. Нужно настраивать Kubernetes-aware мониторинг, разбираться с infrastructure-as-code полноценно. В общем, мышление и практики полностью меняются. И это реально легче для stateless вещей сделать. И если уже опыт есть с standalone базами, то миграция займёт деньги и время. Помните про бизнес и инвесторов. У них тоже есть своё мнение.

Youtube, zalando

И не воспринимайте мои слова, как дисс в сторону Kubernetes. Мы его очень любим и везде используем.

Насколько я знаю, у Zalando там мелкие базы микросервисов. Реальная нагрузка на железных сервачках i3.metal

Насколько я знаю, у Zalando там мелкие базы микросервисов. Реальная нагрузка на железных сервачках i3.metal

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

Иметь несколько нод с одинаковыми лейблами!

так смысл тогда их вообще лейблить?))

так смысл тогда их вообще лейблить?))

Тю я наверно пару недель здесь посижу, и потом заебашу либо БД в контейнере, либо просто БД заебашу.

Если тоже будешь Stolon юзать, то дай знать. Я его чуть попинал, в целом работает, но особо дрючить будем позже.

Пул нод под определённые задачи. Например, CronJob хочу на дешёвых инстансах гонять.

так смысл тогда их вообще лейблить?))

Initial work on a REST service to trigger Spilo deployments on plain AWS/EC2 was scrubbed in favor of a new solution using Kubernetes, believing that this the future platform to run on and benefiting from its feature set, which is a stable API and declarative deployment descriptions https://jobs.zalando.com/tech/blog/postgresql-in-a-time-of-kubernetes/?gh_src=4n3gxh1

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

@SinTeZoiD

Если не считать mysql и кровавого энтерпрайза (который медленно умирает в углу), то другие базы даже на блок девайсе чистом не умеют работать. А если вас послушать, то БД должна быть осью полноценной. Да, есть определенные проблемы с крутилками ядра. Но, если вы действительно понимаете что такое контейнеры, то вы должны осознавать, что запускать один инстанс бд на сервере в контейнере ничем не хуже запуска баре метал, кроме того, что не нужно пилить костыли на ансибле чтобы управлять базами внутри, снимать бекапы и настраивать реплики, всё красиво делается операторами

что-то я пока не видел красивых операторов

там ceph-оператор хипстеры еще не запилили?

а хз я не слежу

там ceph-оператор хипстеры еще не запилили?

Если не считать mysql и кровавого энтерпрайза (который медленно умирает в углу), то другие базы даже на блок девайсе чистом не умеют работать. А если вас послушать, то БД должна быть осью полноценной. Да, есть определенные проблемы с крутилками ядра. Но, если вы действительно понимаете что такое контейнеры, то вы должны осознавать, что запускать один инстанс бд на сервере в контейнере ничем не хуже запуска баре метал, кроме того, что не нужно пилить костыли на ансибле чтобы управлять базами внутри, снимать бекапы и настраивать реплики, всё красиво делается операторами

Хуже - rook