LINUX.ORG.RU
ФорумAdmin

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

 , , ,


0

1

Добрый день,

Подскажите пожалуйста, есть ли смысл в использовании stateful-сервисов в K8S на PROD? Контекст задачи состоит в том, чтобы деплоить в K8S-кластер одновременно РСУБД, NoSQL, MQ-брокеры.

Спасибо.

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

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

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

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

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

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от vbr

vbr ★ (02.04.23 18:48:10 MSK)

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

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

pankina_hr
() автор топика
Ответ на: комментарий от pankina_hr

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

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

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

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

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

vbr ★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr

vbr ★ (02.04.23 20:48:36 MSK)

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

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

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

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

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

pankina_hr
() автор топика
Ответ на: комментарий от pankina_hr

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

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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 операций, это тоже никто не одобрит. В итоге, выгоды не вижу пока на данный момент.

pankina_hr
() автор топика
Ответ на: комментарий от pankina_hr

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

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

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

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

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

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

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

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

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

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

intelfx ★★★★★
()
Ответ на: комментарий от pankina_hr

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

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

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

router ★★★★★
()

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

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

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

vinvlad ★★
()
Ответ на: комментарий от ugoday

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

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

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

vinvlad ★★
()
Ответ на: комментарий от ugoday

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

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

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

ugoday ★★★★★
()
Ответ на: комментарий от vinvlad

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

George
()
Ответ на: комментарий от George

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

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

vinvlad ★★
()
Ответ на: комментарий от George

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

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

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

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от George

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

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

Повторяю:

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

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

vinvlad ★★
()
Ответ на: комментарий от vinvlad

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

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

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

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

vinvlad ★★
()
Последнее исправление: vinvlad (всего исправлений: 1)
Ответ на: комментарий от ugoday

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

@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

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

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

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

router ★★★★★
()
Ответ на: комментарий от intelfx

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С+операторы?

pankina_hr
() автор топика
Ответ на: комментарий от router

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.

pankina_hr
() автор топика
Ответ на: комментарий от pankina_hr

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

vinvlad ★★
()
Ответ на: комментарий от router

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

George
()
Ответ на: комментарий от vinvlad

vinvlad ★ (05.04.23 04:49:21 MSK)

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

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

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

pankina_hr
() автор топика
Ответ на: комментарий от ya-betmen

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

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

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

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

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

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

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

pankina_hr
() автор топика