что за навязчивая идея совать базы данных в кубер?
что за навязчивая идея для каждой задачи поднимать виртуалку?
Vadim
Andor
какую виртуалку?
Andor
у вас базы данных в проде в виртуалках?
Etki
а нафиг тогда вообще кубер, если всё будет друг к другу привязано?
В чем разница для этой утилиты между обычной работой и работой внутри контейнера, внутрь которого примаунчена директория?
Andor
зависит от конкретной утилиты
Etki
Да ни в чем
Andor
вы девопс?
No1
Андрей познаешь мир кубернетеса? 🙂 страдай 🙂
Andor
не, ну у нас бд в виртуалках, но у нас прода 3рпс и виртуалки эти - рдс
Andor
остаётся только вопрос целесообразности
Alik
А какого облачного провайдера вы рекомендуете для кубернетес? с дц в россии?
Sergey
А есть облачные провайдеры с дц в России?
Andor
есть селектеловское облако и у ростелекома что-то было
Andor
но хз как они с куберами
Sergey
У Ростелека SAP вроде как
Sergey
А своего честного iaas я не уверен что у нас оно вообще есть. Вроде как КРОК и прочие интеграторы делают private cloud при желании, но это будет далеко не aws или gcp
Logan
майкрософт то ли открыл ЦОД в России, то ли планирует. Но этот цод недоступен обычным клиентам
Stanislav
а нафиг тогда вообще кубер, если всё будет друг к другу привязано?
к ноде то не привязано - уедет на соседнюю в случае вылета ноды и там смонтируется
Andor
откуда смонтируется? с локального диска вылетевшего сервера?
Etki
мы же про pv
Andor
какой pv? откуда он у вас на другом сервере возьмётся?
Sergey
А pv физически как будет реализован? Сетевой базу в проде может и не устроить
Etki
persistent volume
Etki
Все началось с обсуждения pvc для баз данных. PV, конечно, может быть тупо локальной папкой, но обычно все-таки это сетевое решение, которое свободно ездит между нодами.
Andor
например?
Andor
речь была про запихивание БД в кубер
Etki
В какой сторадж лучше всего писать базы данных? Где sla и скорости будут повыше?
Andor
в локальный
Etki
Ну, по-моему сам по себе вопрос подразумевает не то выбор PD в GKE, не то провайдера для PV.
Sergey
От базы зависит. Кассандра например напрямую рекомендует деплоится на эфемерные ssd в амазоне
Andor
https://console.cloud.google.com/sql/instances это что ли?
Sergey
В любом случае базы сильно чувствительны к io latency и любят локальные диски
Etki
https://console.cloud.google.com/sql/instances это что ли?
oh jesus https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Andor
Возвращаясь к вопросу: зачем пихать базу в кубер если можно взять cloudsql/rds?
Etki
помимо классики есть еще миллард хранилищ, которые как раз чуть лучше работают с горизонтальным масштабированием и они даже скорее более ожидаемы в приложениях, которые деплоятся в кубер, чем собственно SQL-классика
Etki
хоть тот же elasticsearch
Etki
не говоря уж про извечную боль в этой стране с необходимостью хранения личных данных в пределах страны
Andor
Хорошо, что я уехал
Andor
Но тут тоже есть gdpr
Andor
Но оно не про географию
Etki
well thanks for letting us know
Andor
помимо классики есть еще миллард хранилищ, которые как раз чуть лучше работают с горизонтальным масштабированием и они даже скорее более ожидаемы в приложениях, которые деплоятся в кубер, чем собственно SQL-классика
Кажется, последняя фраза очень надумана. На прошлой работе были десятки (под сотню) жырных хостов мускулей и куберы. На это работе постгресы и куберы
Etki
Да я все к тому, что аргумент "не может быть никаких причин пользоваться чем-то другим" не соответствует реальности. Вопросы производительности на PV, приаттаченном по сети и стоит ли такая игра свеч - это уже совсем другой разговор.
Vadim
насколько я понял вот это - http://vitess.io/overview/ - может и с локальными PV работать
Andor
насколько я понял вот это - http://vitess.io/overview/ - может и с локальными PV работать
Насколько мне известно, витесс работает только у разработчиков витесс
Vadim
Насколько мне известно, витесс работает только у разработчиков витесс
https://github.com/youtube/vitess/blob/master/ADOPTERS.md
Andor
Но у меня в голове ассоциации вызванные тем, что было полгода назад
Sergey
на самом деле это вопрос из разряда холивара. есть люди, которые считают, что базам в кубере не место (например, я или @Andorka), а есть те, кто считают что это норм. никто тут никого не переубедит, просто я, например, не вижу никакого бенефита от деплоя базы в кубер, а геморр обычно конкретный и приводящий к прибиванию под к нодам гвоздями, потому как базам нужны свои sysctl, нужны hostPath PV-шки итд
Vadim
нет, ну вопрос был "зачем", ответ простой - scalability
G72K
Возвращаясь к вопросу: зачем пихать базу в кубер если можно взять cloudsql/rds?
Не везде есть cloudsql/rds, не всем хочется быть насильно обновленными, не все базы представлены в rds и не все их конфиги доступны. Причем здесь куб вообще? RDS это про вопрос "пускаем базы сами или у кого то". Вот если ответ "сами", то уже обсуждаем в кубе или нет.
Stanislav
нет, ну вопрос был "зачем", ответ простой - scalability
Горизонтальная масштабируемость реляционки? Бугога
Vadim
еще один не слышал про Слак и Ютуб?
Andor
vitess очень особенная реляционка
Andor
настолько, что у тебя приложение должно знать, в какой шард писать
G72K
Горизонтальная масштабируемость реляционки? Бугога
Почему только скалабилити баз? Есть еще скалабилити людей, процессов. Иметь единую среду деплоя, мониторинга, разделения ресурсов очень удобно, помогает взаимозаменяемости
Stanislav
настолько, что у тебя приложение должно знать, в какой шард писать
Но вот тут считают это масштабируемостью БД, а не заслугой приложения.
Vadim
настолько, что у тебя приложение должно знать, в какой шард писать
можно гадать, а можно прочитать history и узнать что vitess вот эту часть кода заменяет
Andor
ну я про то, как у нас пытались витесс внедрять
Andor
могу позвать в чятик человека, который непосредственно им занимался с полгода наверное
Andor
но это будет уже совсем оффтоп
Andor
Ну!
Mikhail [azalio]
на самом деле это вопрос из разряда холивара. есть люди, которые считают, что базам в кубере не место (например, я или @Andorka), а есть те, кто считают что это норм. никто тут никого не переубедит, просто я, например, не вижу никакого бенефита от деплоя базы в кубер, а геморр обычно конкретный и приводящий к прибиванию под к нодам гвоздями, потому как базам нужны свои sysctl, нужны hostPath PV-шки итд
У мен до сих пор стоит на реализацию галеры в бла бла бла карс в кубере
Mikhail [azalio]
Наверное потому что я не попробовал сам
Sergey
Вас ист галера?
Anonymous
Просто я-то ингресс создал, но не совсем понятно - куда направлять траффик в ДНС? Service типа LoadBalancer (как в случае с nginx-ingress-controller) - нету, соответственно не могу привязать ДНС к этому LB. И еще, сервисы обязательно должны быть типа NodePort чтобы оно взлетело?
В интерфейсе GCP можно увидеть, можно через kubectl get ingress
Sergey
Да, уже победил, спс
Anonymous
У себя вместо ингрессов создаю всю обвязку (backends, url maps etc) через терраформ
Sergey
http://wiki.opennet.ru/Galera
Читнул, вообще при их модели репликации возникают вопросы к масштабируемости записи. Но вообщем-то это опять-таки не про кубер, а про саму базу. Вопрос скорее "что вам дает конкретно кубер" даже в случае подобных решений? Вы будете автоскейлить поды базы через HPA? Тут опять-таки начнутся пляски с бубном: если база большая, то нужно колхозить какой-то свой способ первоначальной репликации при вводе новой ноды, при этом нужно подбирать параметры HPA так, чтобы автоскейлинг не происходил слишком часто, итд
Mikhail [azalio]
Читнул, вообще при их модели репликации возникают вопросы к масштабируемости записи. Но вообщем-то это опять-таки не про кубер, а про саму базу. Вопрос скорее "что вам дает конкретно кубер" даже в случае подобных решений? Вы будете автоскейлить поды базы через HPA? Тут опять-таки начнутся пляски с бубном: если база большая, то нужно колхозить какой-то свой способ первоначальной репликации при вводе новой ноды, при этом нужно подбирать параметры HPA так, чтобы автоскейлинг не происходил слишком часто, итд
Я вообще не задумывался об этом и тоже считаю что на данном этапе лучше базы хранить отдельно. Но мне понравился рассказ бла бла бла карс как у них все устроено.
Mikhail [azalio]
Ну и у них думаю хайлоад, значит есть возможность и смысл
Mikhail [azalio]
Сомневаюсь что сделали это ради статьи в блог :)
Etki
Не могу все-таки не вставить: любое "ХХХ решение горизонтальной масштабируемости поверх MySQL / PostgreSQL" не работает вообще в принципе (точнее работает до первой реальной проблемы), потому что делает вид, что конфликтов не существует, а вот атомарный распределенный коммит - как будто бы и да.
Если бить на шарды, то, конечно, от приложения-прослойки есть небольшой смысл, но с тем же успехом можно прямо в приложение функцию определения шарда загонять.
Stanislav
Расскажите это ребятам из Citus Data