Нужно ли использовать Kubernetes для stateful сервисов на PROD?

Вариант 1: использовать управляемые сервисы (когда админят за вас). Если вы в облаке и вам доступны эти сервисы. Обычно это самый хороший вариант.

Вариант 2: использовать физический сервер. Если из БД нужно выжимать всё до максимума, у вас есть крутые серверы для БД и есть специалисты, которые могут это всё настроить.

Вариант 3: если вы свою БД запускаете в виртуалке или докере, то в принципе нет никаких существенных причин не запускать её в кубере. А плюсы в виде однородной инфраструктуры - есть. При этом в целом пространство для тюнинга очень большое. К примеру можно выделить для БД отдельный сервер, на котором кроме неё ничего не будет, можно использовать локальные диски. То бишь лично я особого отличия от варианта 2 не вижу в плане производительности. Что в контейнере процесс постгреса работает, что без контейнера, для линукса это примерно одно и то же. Тут скорей в предпочтения админа БД упирается, если таковой есть в наличии, ему может быть удобней работать с голой ОС, без прослоек.

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

Неочевидный плюс базы в кубере - операторы. Они могут абсолютно без какой-то настройки делать штуки вроде запуска постгреса в кластере из трёх инстансов с автоматическим фейловером, с постоянным бэкапом в S3. Самому такое настраивать может быть сложно, а тут две строчки и оно работает. И в принципе иметь такое хотят все для продакшна. Это же маст хэв - если сдох сервер, база продолжает работать, если надо откатить базу на 15 минут назад - не проблема. Ну если поломается, то разбираться, конечно, придётся. У меня пока не ломалось.

Имеет смысл их использовать в DEV и TEST. На PROD это выстрел себе в ногу

Нет.

А плюсы в виде однородной инфраструктуры - есть.

Это не плюс, это минус.

vbr ★ (02.04.23 18:48:10 MSK)

Неочевидный плюс базы в кубере - операторы. Они могут абсолютно без какой-то настройки делать штуки вроде запуска постгреса в кластере из трёх инстансов с автоматическим фейловером

Такой еще вопрос, а как операторы работают в контексте репликаций? Состояние и консистентность данных баз - критический момент. Допустим у меня терабайтные базы и сломалась реплика. Не усложнят ли операторы процесс починки кластера баз данных?

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

Если у тебя что-то поломалось, тебе придётся разбираться, как это всё настроено и работает, разбираться, что поломалось и как это починить. Лучше, конечно, разбираться с этим загодя.

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

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

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

vbr ★ (02.04.23 20:48:36 MSK)

С другой стороны если у меня сломается реплика, я её просто удалю и создам чистую реплику, на которую оператор сам накатит копию базы.

В ряде случаев это невозможно почти… Я с точки зрения бизнес-кейсов имею ввиду. У меня есть терабайтные базы, просто с нуля создать чистую реплику не прокатит. Не сможешь ты объяснить владельцам фирмы, что нужно терабайтные реплики с нуля накатывать и ждать N-часов, а то и суток.

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

За объяснения спасибо. Но если честно пока плюсов мало вижу, т.к. как ни крути прибит гвоздем к данным.

Оркестрировать легко stateless приложениями, т.к. они свободно могут между нодами перемещаться. А тут возникает проблема… Что не можешь просто так перекинуть процесс базы с ноды на другую ноду, пока не проработаешь консистентность данных.

У меня есть терабайтные базы, просто с нуля создать чистую реплику не прокатит. Не сможешь ты объяснить владельцам фирмы, что нужно терабайтные реплики с нуля накатывать и ждать N-часов, а то и суток.

Значит, выбираешь и настраиваешь оператор так, чтобы не накатывать с нуля, а делать что-то умнее.

intelfx ★★★★★ (03.04.23 03:41:45 MSK)

Значит, выбираешь и настраиваешь оператор так, чтобы не накатывать с нуля, а делать что-то умнее.

Может умнее тогда вообще ничего не делать с операторами? Объективно разбираем ситуацию с К8С и операторами для РСУБД:

1). Помогают ли операторы решать проблему с обработкой реплик? Нет. Приходится пользоваться стандартными утилитами для починки. Только еще доп. абстрактный слой.

2). Могу ли я свободно оркестрировать контейнерами РСУБД между нодами? Опять не могу, ибо state. И чем более он продуктинвый, то более проблемный.

3). Рассказы про «быстро снести и заново» опять не работают на рабочих огромных базах. Никто не позволит экспериментировать с терабайтными базами.

В итоге логический вопрос «а это равзе умнее?». Какая конкретная выгода предоставляется? Наклейка «works in K8S with operators» как-то не нужна. Я искала определенную выгоду, но если честно пока ее не вижу, кроме как того, что это будет работать в К8С с модными операторами. Но какой в этом смысл? К8С ради К8С? Единственное, это если есть уже К8С-кластер и иного способа развернуть РСУБД - нет или привязка к «облакам». В ином случае это спорно.

Если будет использоваться localPV для дисков, это прибивает К8С-приложения гвоздем к определенным нодам, что нивелирует плюсы К8С. Если дистрибутивные FS использовать, то будет деградация производительности из-за допол. слоя I/O операций, это тоже никто не одобрит. В итоге, выгоды не вижу пока на данный момент.

Помогают ли операторы решать проблему с обработкой реплик? Нет.

Что такое «проблема с обработкой реплик»?

Могу ли я свободно оркестрировать контейнерами РСУБД между нодами? Опять не могу

Нет, а зачем? Это же не единственный смысл k8s — тасовать контейнеры между машинами.

Рассказы про «быстро снести и заново» опять не работают на рабочих огромных базах. Никто не позволит экспериментировать с терабайтными базами.

Экспериментировать нужно с экспериментальными базами, а на терабайтные выкатывать уже готовую отработанную технику :) Что с k8s, что без него.

Какой-то странный аргумент ради аргумента у вас.

В итоге логический вопрос «а это равзе умнее?». Какая конкретная выгода предоставляется? Наклейка «works in K8S with operators» как-то не нужна.

Вроде уже сказали, что выгода — как самого k8s, так и операторов — в удобстве: в однообразном управлении машинами, софтом, базами. Оператор это слой абстракции, который, как и любой слой абстракции, упрощает решение часто возникающих задач.

Так-то, к8s — точно такой же слой абстракции. Если удобство не считать за выгоду, то зачем k8s в принципе? Можно руками бинарники на сервера раскидывать.

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

Но если кубер уже есть и вы с ним достаточно на «ты» — то БД в кубере это вполне себе вариант.

Если будет использоваться localPV для дисков, это прибивает К8С-приложения гвоздем к определенным нодам

persistant volume как правило внешние (csi driver, реже iscsi/nfs/cephfs/fc), а не прибитые к отдельным нодам

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

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

Сделай стейжинг таким же, как прод, как минимум по конфигурации окружения, в чем проблема-то? Казалось бы, очевидная вещь.

есть ли смысл в использовании stateful-сервисов в K8S на PROD? …

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

Вариант поднятия СУБД-шек именно в K8S был выбран, просто потому что изначально, при перезде в GKE из VPS-ки, было заранее известно, что через некоторое время придется поменять облачную платформу. Поэтому желательно было иметь максимально переносимый код кластера. Последующий перезд в AWS прошел без всяких проблем и абсолютно незаметно для программистов. Ну и стиль и командные средства администрирования кластера абсолютно не поменялись - просто пришлось кое-что в Bash-скриптах подправить.

… Еще, как уже было сказано выше, надо учитывать тот факт, что дисковая память в K8S - сетевая.

А раз прод должен быть таким же, как и проверочные окружения, это значит «прод на k8s».

можно и локальные диски использовать. Это лишит возможности перебрасывать pods между узлами, но ведь и без k8s такой возможности нету.

можно и локальные диски использовать…

Да чего-то не встречалась поддержка типовых k8s-узлов с прикрученными локальными дисками - да еще с такими, чтобы данные на них постоянно хранились. Временные локальные диски, содержимое которых удаляется при удалении или перегрузке самого узла - такое есть. А так… даже рутовая файловая система узла - и та, как правило, на сетевом диске болтается.

Если можно, ссылочку - просто любопытно.

А раз прод должен быть таким же, как и проверочные окружения, это значит «прод на k8s».

По части СУБД-шек - не обязательно. Главное, чтобы версии и конфигурации СУБД-шек были идентичны.

Главное, чтобы версии и конфигурации СУБД-шек были идентичны.

Теперь вам нужно поддерживать k8s, отдельный узлы для СУБД и самокатный скрипт для синхронизации версий, конфигов и пр. артефактов. Мои поздравления.

Всё так и есть, потому как производительность сетевых файловых систем обычно не явлется проблемой. Но если вы вот так вот уверены, что всё тормозит именно из за CEPH, а вот ежели по старинке делать, то не тормозило бы, то вы вольны использовать https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ чтобы прибить pod к конкретному узлу и там можно использовать локальный диск точно так же, как если бы вы бд запускали без всяких контейнеров.

… то вы вольны использовать https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ чтобы прибить pod к конкретному узлу и там можно использовать локальный диск точно так же, как если бы вы бд запускали без всяких контейнеров.

Это, типа, самому K8S поднимать на «bare metal» серверах? )

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

Если у тебя уже есть managed k8s, то почему бы не сделать там же managed pgsql/mongodb/etc? Плюс облаков, это как раз отсутствие заморочек с обслуживанием, а ты вот так взял и лишил себя этого.

… то почему бы не сделать там же managed pgsql/mongodb/etc?

Да потому что «managed» СУБД-шки ограничены в диапазоне предлагаемых версий и настроек. Не так все и идеально на практике - со своим спокойнее и надежнее.

Внезапно - managed k8s имеет ровно те же «особенности»

Внезапно - managed k8s имеет ровно те же «особенности»

А какое отношение «managed k8s» имеет к «managed» СУБД ? )

Главное, чтобы собственные yaml-файлики не менялись особо. Пустой начальный k8s-кластер, естественно, по разному приходится создавать у каждого облачного провайдера - но это же мелочь. А вот далее накатываемая нагрузка, её администрирование, деплой и пр. уже идет без изменений, если все толково продумать.

А если вы в облаках уже, то у вас и база данных скорее всего присутствует в качестве API Endpoint.

Прод делаешь исходя из архитектуры

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

А если вы в облаках уже, то у вас и база данных скорее всего присутствует в качестве API Endpoint.

Повторяю:

Да потому что «managed» СУБД-шки ограничены в диапазоне предлагаемых версий и настроек.

Прочувствовал это в Google Cloud c ихним PostgreSQL - в результате просто свой инстанс поднял )

Тогда либо поднимайте свой k8s кластер (это не больно), либо ищите подходящего облачного провайдера. Сколько я помню AWS EKS может потребное, но с деталями нужно разбираться.

Тогда либо поднимайте свой k8s кластер

Если это про использование локальных дисков, то я на такие подвиги не способен ) «Kubernetes hard way» - это не мой путь )

Господь с вами, в этом нет ничего сложного, если есть минимальное представление как оно там внутри устроено. Рекомендую посмотреть https://github.com/kubernetes-sigs/kubespray

Ты жирный тролль :D

kubespray - огромный комок спагетти и позорный пример того, что даже на ansible можно сделать говно

Голословненько-так. И я даже не в рамках спора, просто интересно, чего у вас с ним не срослось?

Почему ? Поясни плиз

чего у вас с ним не срослось?

ugoday, pinachet

Я бы не назвал это «не срослось». При необходимости я могу развернуть кластер через kubespray

У меня претензии к тому, как он написан. Его реально писали методом тыка. Либо, может быть, программисты приняли ансибл за язык программирования и пытались накостылять то, чего в нём нет и что делать вообще нельзя. Либо best practice по ansible в то время ещё не существовало, либо авторам кубспрея было лень его читать. Там реально собраны все BAD practice. Более того, там это походу взяли за стандарт

Буквально все

• зависимости между ролями, в т.ч. неявные через meta
• кошмарное злоупотребление jinja вне templates и vars
• почти везде отсутствуют name для task и play
• глобальные переменные. регистрация переменных в одной роли для другой
• некоторые роли вообще не выполняют какую-либо определённую роль (сорри за тавтологию), в них просто выкинули код, чтобы меньше думать о нём
• и такого говна там около 8 мб (мегабайт, карл)

Просто возьми и начни разбираться, где конкретно там происходит какое-либо действие.

Смотри, взять кубспрей и развернуть из него кластер не проблема. Потрахаешься с переменными, но это реально. А теперь представь, что ты этим же спреем решил обновить сертификаты или кластер (что заявлено как одна из основных целей кубспрея). И представь, что-то пошло не так. Чинить это придётся тебе, а не разработчиткам спрея.

Вот например в тему говнокода на ansible https://habr.com/ru/articles/508762/

А вот best practice https://docs.ansible.com/ansible/2.8/user_guide/playbooks_best_practices.html

А теперь надень на нос прищепку и ныряй в kubespray

глобальные переменные. регистрация переменных в одной роли для другой

Тут неудачно выразился, нужно уточнить. В ansible все переменные глобальные, да. И в доке сказано - не пытайтесь запомнить, в каком порядке они определяются. Чтобы не было конфликтов, не делайте конфликты. Один из вариантов - в именах переменных для роли префиксом идёт имя роли

ИМХО

Если хочешь разобраться в архитектуре самого кубера

1. сначала официальная дока
2. потом полирнуть через kubernetes: the hard way

а спрей это шаманский бубен

Ок ,а какую альтернативу по твоему для kubespray ?

intelfx ★★★★★ (03.04.23 09:36:36 MSK)

Что такое «проблема с обработкой реплик»?

Хотя бы самый стандартный случай разберем с pg_rewind в контексте того, как я буду повторять тоже самое но еще в K8S с операторами.

https://www.highgo.ca/2019/11/07/replication-failover-with-pg_rewind-in-pg12/

Here’s a brief overview of list of actions we are going to perform:

• simulate failover by promoting slave cluster, so it becomes a new master
• simulate data insertion to master cluster, also referred as old master after promotion
• shutdown the old master cluster and set it up as a standby server
• run pg_rewind on old master to synchronize transaction states with new master
• bring up old master as a standby server to synchronize with the new master

Допустим, что повторяем тот же сценарий, только с PostgreSQL в Кубере. Сколько дополнительных операций я проведу с учетом абстракции в виде Кубера и операторов? Плюс добавим условия что state - большой (несколько Тб) и допустим, что отставание реплики - 30 Гб данных (имеется ввиду второй шаг «simulate data insertion»).

intelfx ★★★★★ (03.04.23 09:36:36 MSK)

Нет, а зачем? Это же не единственный смысл k8s — тасовать контейнеры между машинами.

Хорошо, расскажите пожалуйста вкратце своими словами какой смысл у К8С еще есть. Может я дейсвительно что-то не понимаю.

intelfx ★★★★★ (03.04.23 09:36:36 MSK)

Экспериментировать нужно с экспериментальными базами, а на терабайтные выкатывать уже готовую отработанную технику :) Что с k8s, что без него. Какой-то странный аргумент ради аргумента у вас.

Так это не аргумент. Это я отвечала другому человеку (vbr) в теме, который предлагал все снести.

vbr ★ (02.04.23 20:48:36 MSK)

С другой стороны если у меня сломается реплика, я её просто удалю и создам чистую реплику, на которую оператор сам накатит копию базы.

В этом и была суть сообщения, что просто так нельзя снести. Что вполне себе рабочая ситуация, что ты не сможешь снести стейт, создав «чистую реплику» и не можешь ждать по несколько часов или суток, ожидая sync статуса по репликам.

vbr ★ (02.04.23 20:48:36 MSK)

Вроде уже сказали, что выгода — как самого k8s, так и операторов — в удобстве

Так а в чем «удобство» заключается? Давайте разберем пример, который в самом начале моего сообщения с симуляцией failover и внесением лишних данных, которые потом нужно нагнать репликой.

Возьмем для сравнения:

1). Две VMs с Постгрес-инстансами (master-slave).

2). Аналогичный пример с К8С, где мастер и слейв в разных подах на разных нодах и обязательно учтем использование операторов еще.

Количество операций в случае первого вар-та будет таким же, как в статье, которую я приложила. А сколько будет операций в случае К8С+операторы?

router ★★★★★ (03.04.23 13:26:23 MSK)

persistant volume как правило внешние (csi driver, реже iscsi/nfs/cephfs/fc), а не прибитые к отдельным нодам

Я же написала четко в своем сообщении, которое же вы сами цитируете:

Если будет использоваться localPV

И тут же вы пишите:

persistant volume как правило внешние (csi driver, реже iscsi/nfs/cephfs/fc)

Причем тут «реже NFS, CephFS»? Если я четко указала слово «localPV»? По ссылке, которую вы шлете написано:

• local - local storage devices mounted on nodes

Вот, что я имела ввиду когда писала про localPV, отсюда и про «прибитость гвоздем» к К8С-ноде. Про CephFS или NFS речи не было. У MySQL есть такая инфо., кстати:

If reliability is a consideration for your data, do not configure InnoDB to use data files or log files on NFS volumes. Potential problems vary according to OS and version of NFS, and include such issues as lack of protection from conflicting writes, and limitations on maximum file sizes.

Молчу про очевидный факт, что базы делают очень много операций связанных с записью в файловой системе. А делать это поверх еще одной абстракции в виде distributed network fs…

Еще более очевидный факт и предложение:

1. Возьмите benchmark тулзу, типа https://ankane.org/tpc-ds

2. Исполните tpc-ds тест на базе с локальным диском и на базе, которая использует volume через предложенный вами вар-т «csi driver, реже iscsi/nfs/cephfs/fc»

Могу сказать заранее за себя. Уже тестили на Ceph RBD с Кубером. Естественно этот вар-т проигрывает против работы базы с прямым доступа к диску под RAID (RAID-1 или RAID-10), причем очень сильно. Поэтому и была речь изначально про local PV.

Если у вас терабайтные базы данных - т.е. всё в кэш не закачаешь - и критически важна скорость выполнения блоковых операций чтения-записи - настолько, что предпочтительно использовать локальные диски - то тут выбор, вроде как, очевиден: гораздо более оптимально использовать выделенные СУБД-шные инстансы, где вся оперативная память отдана СУБД-шке и где можно выполнить всякие тонкие настройки. Более того, если СУБД-шка позволяет работать непосредственно с блоковыми девайсами (типа Oracle, MySQL) то и от использования локальной файловой системы тоже, по идее, лучше бы отказаться - работать непосредственно с разделами дисков.

Ну вот куб под эти все «удобно разрабатывать и тестировать кучу разных версий» очень даже ок, разве нет?

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

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

одновременно РСУБД, NoSQL, MQ-брокеры.

Всегда было интересно для чего люди разводят такой зоопарк.

vinvlad ★ (05.04.23 04:49:21 MSK)

что предпочтительно использовать локальные диски - то тут выбор, вроде как, очевиден

Дорогой vinvlad, так не я же рекламирую K8S, как ультрасредство. Везде пишут и пытаются доказать, что это «лохи и лохушки» не освоили Kubernetes, и мол там все замечательно даже для stateful-сервисов.

А как начинаешь копать, оказывается что не все так классно, а возможно даже хуже чем привичные средства (ну или будешь те же средства использовать, только плюс абстракция ненужная). Акцент данного топика был вокруг следующего, что если есть какие-то реальные удобства и плюсы, то прошу «в студию».

ya-betmen ★★★★★ (05.04.23 11:45:35 MSK)

Всегда было интересно для чего люди разводят такой зоопарк.

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

РСУБД - понятно, что основные бизнес-данные.

NoSQL - 2nd level кэши для ОРМов и другого. Эластик со своими логами, time-series хранилища.

MQ - шина для общения между сервисами, enterprise bus паттерн.

В части разработки ПО - гексагональная архитектура.