Если есть DBA, который знает и умеет в куб, но в случае чего знает и как базу подлатать, то какие могут быть проблемы?

Если есть DBA - он не станет тратить время на бд в кубе. Ибо кол-во мозгоебли в час не стоит полученного результата

У меня против бд в кубе только одно но - если падает кластер, то падает бд 😅 упавшая бд хуже всего

кластер не может упасть.

"кубер не падает"

Если есть DBA - он не станет тратить время на бд в кубе. Ибо кол-во мозгоебли в час не стоит полученного результата

Да ну? А если у вас баз, скажем, больше сотни и вам их надо деплоить постоянно?

кластер не может упасть.

Надеюсь эт тролинг 😱

Не падал с 93

У кого как, а у меня база - оплот стабильности. Рабочая база - не все потеряно 😅

У меня против бд в кубе только одно но - если падает кластер, то падает бд 😅 упавшая бд хуже всего

Что ты понимаешь под падением кластера? Падение etcd? Или воркеров?

Да ну? А если у вас баз, скажем, больше сотни и вам их надо деплоить постоянно?

давайте различать дев-стейдж и продакшен.

давайте различать дев-стейдж и продакшен.

давайте

давайте

вы постоянно деплоите сотни продакшен бд ?

Что ты понимаешь под падением кластера? Падение etcd? Или воркеров?

контрол плейна

контрол плейна

Ну и почему базы должны развалиться при падении контрол-плейна?

для каких целей балансировка с весами нужна ?

Одна нода на i7, вторая на celeron. Домашняя лаба, но всеже.

вы постоянно деплоите сотни продакшен бд ?

У нас хостинг, базы создаются и удаляются постоянно

контрол плейна

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

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

Я понимаю, что все просто. Поэтому куча людей боятся обновить свой кубер.

Даже если уверены, что их сетап работает в новой версии

Одна нода на i7, вторая на celeron. Домашняя лаба, но всеже.

Лучше домашнюю лабу делать в облаке - дешевле

откуда дешевле? Там любой ЛБ по 5-10 баксов

Одна нода на i7, вторая на celeron. Домашняя лаба, но всеже.

Можно на i7 заспавнить больше инстансов)

откуда дешевле? Там любой ЛБ по 5-10 баксов

Тушить все, как закончил развлекаться

Лучше домашнюю лабу делать в облаке - дешевле

А t2 micro, или какие там в aws бесплатные, потянут кубер?

У нас хостинг, базы создаются и удаляются постоянно

а база данных самого хостера тоже в кубе лежит или все таки на выделенных железках ?

Сейчас квапсу расскажут как НА САМОМ ДЕЛЕ у него все устроено

Сейчас квапсу расскажут как НА САМОМ ДЕЛЕ у него все устроено

фу таким быть

а база данных самого хостера тоже в кубе лежит или все таки на выделенных железках ?

Мы активно используем куб и для своих внутренних сервисов в т.ч. и базы в нем деплоим, если вы про dogfooding :) Сама система что общается с кубом и деплоит инстансы работает отдельно и имеет внешнюю базу, но это только по историческим причинам.

А t2 micro, или какие там в aws бесплатные, потянут кубер?

Мне на я.облаке кластер из 3/3 2ядра 4гб на пару часов стоил копейки, рублей 100

откуда дешевле? Там любой ЛБ по 5-10 баксов

в месяц?

в месяц?

ага, на DO например

а много проблем с бд в докере на распределенном хранилище ? У вас постгрес, мускул ? Какое решение для кластеризации бд ? столон, патрони ? галера ? у вас же там наверное 10гиг сеть, NAS и прочие вкусности ? или БД на localvolume ?

а много проблем с бд в докере на распределенном хранилище ? У вас постгрес, мускул ? Какое решение для кластеризации бд ? столон, патрони ? галера ? у вас же там наверное 10гиг сеть, NAS и прочие вкусности ? или БД на localvolume ?

Доклад есть целый про это

Доклад есть целый про это

пруфы ? ;) ссылка есть или хотя бы название ? или ты про Столярова ?

пруфы ? ;) ссылка есть или хотя бы название ? или ты про Столярова ?

Последний митап по кубу от майл ру. Последний доклад

ага, на DO например

для экспериментов вида "поднять кластер, поиграться, потушить" это будет стоить сильно меньше

Последний митап по кубу от майл ру. Последний доклад

смотрю Андрея от 14 февраля. про сервера в масле

для экспериментов вида "поднять кластер, поиграться, потушить" это будет стоить сильно меньше

я считал что "домашняя лаба" == "лаба для домашних нужд из старых ноутов", а не "мне нужен кластер на несколько часов"

а много проблем с бд в докере на распределенном хранилище ? У вас постгрес, мускул ? Какое решение для кластеризации бд ? столон, патрони ? галера ? у вас же там наверное 10гиг сеть, NAS и прочие вкусности ? или БД на localvolume ?

Базы MySQL, мастер-слейв репликация, хранилище LINSTOR и 10г сеть. По проблемам не скажу, т.к. базами занимаюсь не я, а мой коллега, но полагаю что разницы особой нету: если процесс бд может работать на хосте, точно так же он будет работать и в контейнере.

я считал что "домашняя лаба" == "лаба для домашних нужд из старых ноутов", а не "мне нужен кластер на несколько часов"

я тут считал и из расходов на год взять хосты в амазоне выходило дешевле чем "кластерок" из десяти старых ноутов покупать

но если такие ноуты у тебя уже есть прямо щас, то картина другая

Базы MySQL, мастер-слейв репликация, хранилище LINSTOR и 10г сеть. По проблемам не скажу, т.к. базами занимаюсь не я, а мой коллега, но полагаю что разницы особой нету: если процесс бд может работать на хосте, точно так же он будет работать и в контейнере.

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

Проблемы могут возникнуть на control-plane или с той же самой кластеризацией, из-за того что control-plane слег например :)

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

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

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

но если такие ноуты у тебя уже есть прямо щас, то картина другая

Нужно ещё их разложить, подключить у роутеру, плати за электричество и тп. Это не принесёшь на работу или на дачу

я учитывал расходы на электричество тоже

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

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

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

Нужно следовать best-practice и не допускать больше одного процесса на контейнер, ну или хотя бы обернуть в tini, тогда запущенных процессов в системе не остаётся.

Нужно следовать best-practice и не допускать больше одного процесса на контейнер, ну или хотя бы обернуть в tini, тогда запущенных процессов в системе не остаётся.

kube-proxy следует best-practice ?

обновление докера с 17.09 до 18.06 через yum install у меня стабильно приводило к тому, что процесс с kube-proxy оставался работать и занимать порт метрики.

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

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

из-за чего кублет не мог запустить статик под с куб-прокси. и конечно же отрестарченный докер ничего не знал о забытом процессе

обновление докера с 17.09 до 18.06 через yum install у меня стабильно приводило к тому, что процесс с kube-proxy оставался работать и занимать порт метрики.

Про обновление докера ничего сказать не могу, т.к. обновляюсь атомарно через ребут.

Про обновление докера ничего сказать не могу, т.к. обновляюсь атомарно через ребут.

также через ребут делаю. это я все к тому, что докер добавляет своих изюминок

А откуда тогда процесс kube-proxy?

А откуда тогда процесс kube-proxy?

был узел с докер 17.09, докер обновился до 18.06, при обновлении пакета был рестарт докера. после рестарта контейнера нет, а процесс остался работать

А подскажите пожалуйста как исправить неравномерную нагрузку на ноды? одна нода такая: total used free shared buff/cache available Mem: 3.8Gi 3.1Gi 219Mi 203Mi 514Mi 300Mi Swap: 0B 0B 0B а вторая вот такая: total used free shared buff/cache available Mem: 3.8Gi 390Mi 895Mi 200Mi 2.5Gi 2.9Gi Swap: 0B 0B 0B из-за этого переодически вываливается Kubelet stopped posting node status на первой ноде

обновлять пакеты на бегущей системе - это попытка заменить стул под сидящим человеком, неудивительно что это иногда не получается

обновлять пакеты на бегущей системе - это попытка заменить стул под сидящим человеком, неудивительно что это иногда не получается

да ладно

был узел с докер 17.09, докер обновился до 18.06, при обновлении пакета был рестарт докера. после рестарта контейнера нет, а процесс остался работать

А live-restore не используется случайно?

А live-restore не используется случайно?

усомнился. проверил. нет. в кубернетес не используем.

причем с 18.06 до 18.09 такой же апгрейд проходит без проблем и сюрпризов

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

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

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

amazon rds

там тоже можно взять субд, а не мускуль

я учитывал расходы на электричество тоже

Привет. И сколько на эл-во вышло по расчетам, в месяц?

мои рассчёты тебе ничего не дадут, вряд ли у тебя оно стоит столько же

мои рассчёты тебе ничего не дадут, вряд ли у тебя оно стоит столько же

Ты можешь сказать расчёты в килловатах в час

могу, но я их не помню :)

это было летом ещё

Ты можешь сказать расчёты в килловатах в час

Там ещё аренда площади. Аренда/площадь. Ну 0.5 это занимает, при цене 30к 30м2 это 500р аренда площади. И даже если недвижимость своя - стоит считать сколько себе платишь.

Ок. СПб, двухтарифный счётчик, 7 серверов + роутер + свитч, тоже юнитовые ~= 4500 rur \ месяц за эл-во. Охлаждение - freecooling^Wfreeбалконинг :)

да почему серверов-то, старых б/у ноутов

Куб федерация

Полная версия не поместилась?

полную не видел)

https://linuxacademy.com/devops/training/course/name/learn-microservices-by-doing Вдруг кому интересно будет немного теории не очень сложной