Comments 20
Был бы признателен, если кто-то смог бы аргументированно рассказать про преимущества подхода, когда СУБД размещается в контейнерах.
Кроме банальных: "ну, круто же, сейчас всё в контейнерах".
да нет никаких аргументов.
Просто если у тебя уже есть кластер типа кубера или опенщифта, то вместо клепания виртуалок, можно уже и субд в контейнер запустить, чтобы все было в одном месте.
Но если ты в облаке, то проще заказать готовую базу.
А если у тебя не слишком много всего в кубере/опенщифте, и нет требования стандартизировать все, можно делать так, как тебе удобно.
Если используется k8s и gitops, то быстрее и удобнее создавать кластера через k8s оператора+helm/kustomize, чем переключаться на ансибл, терраформ
Ок, а во что в результате обходится это вот "удобнее" если база более-менее серьёзная?
Не совсем понял вопрос. Если отказоустойчивость и бэкапы, то это обеспечивает оператор. Если размер базы и сохранность файлов, то это обеспечивает сторадж контроллер и файловая система
Требуется разбираться в другом стеке технологий, k8s operator + контейнеры против условных lxc + puppet.
Это никогда не было бесплатно, но на больших масштабах (от сотен баз) экономия уже заметна.
Оператор придётся выбирать, тренировать бэкапирование и восстановление, писать доки по типовым операциям типа масштабирования во все стороны.
Это, кстати, может потребовать разбирательств в сорцах оператора. Кроме того, часто даже широко используемые операторы содержат серьёзные баги.
Инфраструктурный код, кстати, тоже тестировать придётся. Видел как кликхаус инсталляция пересоздалась к чертовой матери вместе с данными, из-за бага в версии кубернетес провайдера в терраформе. Проблема тут не в операторе, но тем не менее.
SaaS сервисы не требуют такого вдумчивого подхода - как правило, облачный провайдер уже написал всю документацию, а саппорт поможет с проблемами. В случае с проблемами операторов вам никто в срочном порядке помогать не станет.
+1 - У меня очень похожие мысли:
- всегда рекомендую DBaaS
- поднять надежный сервер БД непросто - нужно знать БД, репликацию, performance tuning, backups, HA и т.п. А если мы это делаем под K8S - то дополнительно нужно еще разбираться с K8S и оператором.
Как насчёт бюджета? DBaaS всё-таки ощютимее дороже.
Как насчет надежности, производительности, scalability, возможности восстановления? За это мы и платим больше.
Я меня большой опыт с MySQL и я хорошо знаю, что поддерживать production-ready кластер очень непросто. А в DBaaS мы получаем это, плюс каждая кухарка может восстановить базу включая Point-in-Time Recovery. А админ может сделать scale up \ scale down одной кнопкой и это будет работать.
Ни в коем разе не сомневаюсь в Вашей компетентности. Но всё-таки надёжность, масштабируемость и возможность востановления это всё очень субъективно. Про производительность даже не говорю. Любое приложение на железке будет производительней (может так же, но точно не хуже) чем в облаке. А уменьшение сложности управления может сыграть злую шутку, когда кухарка решит, что можно начать оптимизировать базу просто выкручивая параметры.
Я имел в виду что поддерживать базу и так непросто, а K8S добавляет свои заморочки.
Я не сомневаюсь, что инсталлировать базу с помощью "helm install" в K8S может любой студент курса DevOps. Но чтобы быть уверенным, что есть возможность восстановления, и чтобы знать что делать когда "все упало" нужен очень серьезный уровень и в DBA и в K8S. То есть дорогой человек или группа. Наверно это окупается когда есть десятки-сотни production баз.
Для небольших фирм я всегда советую оутсорсить все это платя за DBaaS.
Преимущества те же, что и размещение любого приложения в контейнере. Изолированность среды. Данные-то всё равно в контейнер пихать не стоит. А так бегает себе движок в контейнере со своими либами, надо обновить - старый новым образом заменил и готово (конечно + миграция и т.п. ). Опять же дебажить удобно. Образ на десктоп поднял и уверен, что все либы те же. Если вопрос в прозводительности, то контейнеры её точно не прибавят.
Секреты храните в Vault или HashiCorp.
Имелось ввиду наверное HashiCorp Vault.
И да, как уже верно заметили, если есть stateful аппликуха, то нужно сразу искать уже готовый оператор. В большинстве случаев он уже есть. Это cloud-native подход, когда есть управление полным циклом.
пользуйтесь безголовым сервисом
это прям прекрасно
Второй абзац только я не понял?
mysql -u root -p -h mysql-set-0.mysql.default.svc.cluster.local - вот эта строчка подключается напрямую к контейнеру? Или сервис создает "подсервисы" для каждого пода стейтфул сета?
Почему в статье не описаны стандартные сценарии отказоустойчивости?
Что будет с приложением и кластером бд если упадет mysql-set-0 ?
Что будет при проблемах с сетью по типу splitbrain (мастер недоступен ля приложения)?
Понятно что между Deployment и StatefulSet есть разница но отказоустойчивость они обеспечивают примерно одинаковую.
При проблемах с сеть будет всё тоже самое, что и при использовании виртуальных машин или железных серверов.
Если упадёт мастер - нужно будет назначить новый мастер, до тех пор запись в БД будет недоступна. Как и при использовании виртуальных машин или железных серверов.
Как мне кажется, основная проблема в деплое БД в куб - дополнительные точки отказа и добавление нового слоя усложняющего траблшутинг. Это решаемо, но потребует дополнительного времени и ресурсов
Абсолютно не раскрыта тема назначения Persistence Volume. А без этого статья просто бесполезна. Предлагается использовать привязку пода к Persistence Volume через StorageClass? Это какая-то ерунда или я чего-то не понимаю!
StatefulSet в Kubernetes – примеры и наилучшие практики