0 урок DevOps
0 урок DevOps, Теория.
В этом видео рассматриваем микросервисные и монолитные архитектуры, базовые составляющие Kubernetes.
Ссылка на предыдущий урок: -1 Урок DevOps
TG канал где можно позадавать вопросы: https://t.me/pikabu_devops
Что такое монолит и почему его нельзя запустить в кубере?
Мироксервисы бесмертны? Если бд упадет, то поднимется новая? Все разруливается правилами?
Хорошая история, жалко что пиздеж
раскрыть ветку (25)
Монолит - это здоровый кусок скомпиленного кода. Запихнуть в кубер можно, но не нужно. Например, jhipster в одном фэт джаре вместе с фронтом и беком, который выполняет как авторизацию так и апи запросы - самый яркий пример. В кубер пихается, но жрёт неприлично много ресурсов, толком не масштабируется и вообще нахрен там не нужен. Дабы пихнуть его в кубер надо распиливать на микросервисы, независимые друг от друга, а именно: фронт, авторизация, и по сути по микросервису на каждый апи колл. Тогда каждый можно масштабировать в зависимости от определенных условий, в том числе и реализовать полноценный service mesh с прозрачными транзакциями и трейсингом на базе той же связки linkerd+jaeger.
Микросервисы смертны и ещё как. Задача оркестратора (кубера) отслеживать их здоровье и поднимать/опускать/масштабировать в зависимости от проб и нагрузки.
Касаемо бд - нефиг вообще на проде держать stateful нагрузки в кубах. Они не про это. Бд прекрасно кластеризуются и живут вне кубера или предоставляются клауд провайдером по схеме SaaS. Для дев сред никто не мешает поднять под с той же постгрей, но нужно понимать что в любой момент это может наебнуться.
Кубы про stateless приложения, которые не зависят друг от друга и спокойно переживают рестарты/масштабирования.
Надеюсь, ответил на ваши вопросы.
раскрыть ветку (2)
да у меня к автору вопрос был, особенно про фокус с "монолит - пропадает бд и все падает, а микросервисы заебись и все живет".
и монолит, если он stateless, можно пихнуть в кубер и масштабировать.
разные поды с одним и тем же образом бека, а на nginx разделить, что куда пойдет.
и будут у тебя поды с одинаковым кодом:
- авторизация
- админка
- хуе-мое
и сможешь ты нормально мониторить, что именно и где тормозит, и масштабировать нужное (например увеличить число реплик подов с авторизацией)
Переписать под кубер с нуля конечно лучше, но кто-же это будет делать, особенно для тсарых проектов. Это не бесплатно как по стоимости разработки, так и по факапам, которые точно будут, при переписывании с нуля. А с легаси вполне можно работать в кубере, с масштабированием и т п. Это будет менее приятно(на самом деле ебать как неприятно) и дороже по железкам немного, но намного дешевле, чем переписывать
раскрыть ветку (1)
и будут у тебя поды с одинаковым кодом:Так и буду называть разделы. Коротко, ясно, логично.
- авторизация
- админка
- хуе-мое
Обоснуйте? Почему нельзя запустить монолит в кубере? Я такого не говорил, я сказал что это нежелательно. Хорошо спроектированная микросервисная архитектура не падает, при адекватном DR. Что из того что я сказал пиздеж? Если хоть 1 слово наврал, то согласен удалиться отсюда и больше не появляться, если же выясниться что нет то удаляетесь вы, идет?
раскрыть ветку (21)
кубер вещь хорошая и при правильном подходе решает кучу проблем, но вот БД в нем не бессмертные.
Давай я лучше спрошу, какие ты бд завернул, какой там объем данных и какой qps?
Да ладно, не кипятись, полезная штука эти ваши микросервисы, но если у бд нет физических реплик с нонстоп синхронизацией(а это тот ещё гемор, либо мастер будет ждать слейвы и тормозить от перебоев связи, например, либо так себе синхронизация ) , то при падении БД пизда рулю. Что будет поднимать кубер? Бд из бэкапа с отставанием?
раскрыть ветку (19)
раскрыть ветку (18)
Master Master это пишем в оба и оба синхронизуются друг с другом. Если кто-то видел такое при хорошей нагрузке и когда стораджи не на соседних полках отпишите, интересно.
Более менее рабочий вариант, когда слейв при падении мастера становится мастером, но тут 2 варианта, либо слейв писался без обеспечения целостности в асинхроне не тормозя мастер и в синхроне, что опять же накладывает требования на то что слейв у нас блокируещее звено(но тут благо их можно сделать много)
раскрыть ветку (15)
Так при нагрузке шардируешь. Тут то речь про надежность. Можно сделать master master и еще шардировать это дело.
раскрыть ветку (14)
А можно не мучать жопу и не держать stateful нагрузки типа БД в окружении для них не предназначенных. Бд прекрасно живут и вне кубера, либо как SaaS.
раскрыть ветку (13)
То, что у вас БД будет жить вне кубернетеса, как то отменяет репликацию и шардирование?
Кубер это всего лишь вариант как управлять вычислительными ресурсами. Вы можете подымать виртуалки, а можете контейнеры. По сути это как иметь скрипт и конфиг с параметрами для него. Только по сути скрипты написаны, осталось заполнить конфиг. БД в кубере точно также для внешнего пользователя будет как SaaS а для админа точно такой же геморой с шардированием и репликацией.
раскрыть ветку (12)
Все верно, репликацию и шардирование бд это никак не отменяет. Бд это зона ответственности dba, вообще не надо её в кубер пихать, особенно на проде.
раскрыть ветку (11)
Ну тут уж кому как, если люди уверены в своих силах, умеют это готовить, то почему нет? По сути обычно там выделяется под базу несколько отдельных хостов. Все это настраивается, шардирование и репликация, организуется как сервис, настраиваются сайдкары и амбасадоры и все у вас готовая к расширяимости бд. Разве что настроить все это задача совсем не тривиальная. Но в итоге получается единое облако и настройки в едином стиле (Мониторинг потребления ресурсов, алертинг и т.д.). Как то был доклад на этоу тему от компании Флант.
раскрыть ветку (10)
Ага, потом ноды с бд перекатываются, репликация идёт по одному месту, и вы судорожно ищете бекапы. Не надо бд в бою держать в кубере.
раскрыть ветку (9)
А зачем делать чтобы ноды бд перекатывались? Я же говорю, что ноды прибиваются гвоздями к хосту и никуда ничего не перекатывается
раскрыть ветку (8)
Затем что кубер штука динамическая. И облака тоже так-то не дают 100% гарантии что с нодой ничего не случится. Нод пул может сам по себе перезаказать инстансы, и никакое прибивание гвоздями не поможет. Ну и гвоздями прибить можно и без кубера, зачем себе усложнять жизнь и какой будет профит от бд в нём?
раскрыть ветку (7)
Так собственно на выступлениях по БД в кубере и рассказывают о том как его прибивать гвоздями. Нод пул не может ничего сделать с инстансами прибитыми гвоздями, жизнь ничуть не усложняется если знаешь как это делается, а профит в том, что все остальные сервисы видят бд как еще один сервис и работают с этим и вы можете делать доп окружение над базами в виде сайдкаров и амбассадоров, например для шардинга, использовать балансировку и вообще организовать над ними service mesh. На управлении БД это абсолютно никак не сказывается, так как она крутится на хосте с заранее заданным числом ресурсов и никуда никогда не может быть перенесена.
раскрыть ветку (6)
Чтобы иметь сервис бд внутри кластера для меша достаточно этот самый сервис создать с EP смотрящим на внешнюю бд. Для этого совсем не обязательно тащить всё в кластер. А то что рассказывают - это дикие костыли. Не надо так. Это из серии про буханку и троллейбус из неё.
раскрыть ветку (5)
раскрыть ветку (4)
Так вот я и пытаюсь понять - кому в здравом уме и твердой памяти надо тащить базы данных на проде в кубы? Какой профит с этого кроме геморроя?
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
Я же написал, чтобы все было в одном месте, чтобы удобно обвешивать доп облачными плюшками, но вы явно не желаете читать мои сообщения.
Не панацея при большом qps. Здесь ближе все таки шардирование данных и более глубокая работа с бд приложения.
(пс: если упомянал в ролике, то респект, само видео не смотрел)
речь видимо о мускуле?
помимо этих вопросов #comment_182689015
раскажи, а master-master прям писать в 2+ инстанса приложениям, или как?
Лига Сисадминов
2.7K постов19.2K подписчиков
Правила сообщества
Мы здесь рады любым постам связанным с рабочими буднями специалистов нашей сферы деятельности.