Comments 19
В это истории не совсем понятно:
Почему изначально при выборе решение был выбран GKE понимая что основной продукт компании в основном для рынка Украины и если задержки критичны то размещаться изначально нужно было в Украине. Интересно чем тогда руководствовались.
Я более чем уверен что и раньше стоимость GKE была выше чем собственный сервер в ДЦ в Украине. Получается что тогда кто-то решил за деньги компании получить для себя и команды опыт работы с GKE?=)
Насколько текущее решение с прицелом на будущее а не решение текущей проблемы? Основная мотивация всей затеи снижение затрат на k8s? ЗП одного инженера с лихвой может перекрывать траты на инфру)
На первый вопрос логичным ответом звучит то, что еще тогда сразу требовалось managed-решение:
У ИТ-команды robota.ua не было опыта работы с Kubernetes, поэтому managed-сервис стал самым рациональным способом кубернетизировать приложения.
А из чего было выбирать в самой Украине?..
По третьему вопросу: график хорошо показывает, что с ростом кластера затраты на текущий вариант Kubernetes'а становятся только выгоднее (по сравнению с managed-решением от крупного провайдера). Если говорить про сравнение с зарплатой, то ведь логично (раз сейчас всё устраивает), что и инженер из-за растущей инфраструктуры: а) понадобится позже, б) будет решать более высокоуровневые задачи по инфре, оставив низкий уровень платформе Deckhouse (об этом был такой наш доклад).
Да немного пока писал комент потерял инфу. Спасибо что указали.
В Украине и сейчас получается не из чего выбирать) Я как бы локальный рынок Украины знаю еще с 2000 годов когда занимался телекомом и на моих глазах росли сети и так называемые "серверные". Игроки одни и те же остались по сути) Тот же collocal как был тогда так и сейчас есть.
У меня все так же остаются вопросы и их много. А так спасибо за работу и за продвижение технологий)
Очень странное решение. Компания четко просчитала риски связанные с переездом в облако мелкого провайдера? Маски-шоу вроде как запрещены, но никто не застрахован, что могут отрубить часть инфры или вывезти пачку серверов. Также как быть со скейлингом - если резко возрастет нагрузка, а у провайдера не будет ресурсов.
Все эти риски естественно присутствуют. Также если говорить, например, про РФ, есть риски, что будут блокировки иностранных облаков со стороны Роскомнадзор. Или есть разные федеральные законы, которые могут создать проблемы с использованием облачных услуг у иностранных поставщиков.
В статье мы постарались дать понимание, что "стоимость вм" - это один из факторов, который стоит учитывать. Скейлинг и отказоустойчивость - это сильные преимущества Google Cloud.
Важная оговорка. Понятно, что GKE — это лишь часть огромной экосистемы Google Cloud. Она дает широкие возможности, решает большой объем задач, у нее высокая отказоустойчивость. Разные проекты используют эти возможности по-разному. В случае robota.ua команде нужен был только «голый» GKE, без дополнительных managed-сервисов — например, БД или мониторинга от Google. Поэтому миграция на другое решение managed Kubernetes оказалась целесообразной и простой. Однако в других случаях при оценке экономической эффективности переезда стоит учитывать все нюансы.
Одним из преимуществ Deckhouse и услуги, которую мы предоставляем на базе этой платформы, является одинаковый для пользователя Kubernetes. Таким образом, если возникнут проблемы с текущим провайдером, то мы достаточно легко перевезём кластера клиента к другому. Это частично защищает от указанных рисков.
Это больше вопрос к robota.ua, чем к Вам, как разработчикам платформы.
вы абсолютно правы, только вот интересно (техническая деталь) - в GKE кластера размазаны были по разным AZ и были толерантны к отказу одного провайдера/ЦОДа гугла и пр.? В случае же некоего украинского провайдера есть высокая степень вероятности, что уровень отказоустойчивости будет просто на порядки ниже. Простой пример - заказали Вы ВМки, накатили на них кластер, ВМки попали неудачным образом на один гипервизор. Он шлепнулся. Кубернетес нам не помог. Потому что сам валяется. А про топологию под капотом они ничего не знает. Или. ВМки попали на разные гиперы, но в рамках одной стойки или одного СХД. Стойка обесточилась или на нее сверху протек кондиционер, или СХД отказало. Опять же - вроде кубер есть, только толку? Как решали в этом случае эту проблематику?
Я полностью согласен, что в облаке небольшого провайдера отказоустойчивость на порядок ниже, чем у Google или AWS. К сожалению, в данном публичном облаке Colocall у нас нет возможности управления распределением вм по гипервизорам. Таким образом, мы даже не можем гарантировать, что ноды control-plane находятся на разных гипервизорах или тем более на гипервизорах в разных стойках. Этот тот риск, который надо обязательно брать в расчёт.
Если говорить в целом про небольших провайдеров, то у многих помимо публичного облака есть услуга приватного облака. Тут ситуация лучше, так как они обычно выделяют гипервизоры в разных стойках. Таким образом, мы закрываем часть проблем. Но если уж отказало СХД, то, скорее всего, это будет фатально. Опять же такие приватные облака обходятся дороже, чем публичные. Решение и принятие рисков здесь полностью на стороне бизнеса.
А спот инстансы рассматривали?
Спот инстансы подходят не всем клиентским приложениям, но это действительно один из лучших способов сэкономить. Также можно рассмотреть "1 year commitment" или "3 year commitment" планы. Перед компанией Флант не ставилась задача уменьшения стоимости эксплуатации GKE, поэтому тут, к сожалению, не можем привести точного расчёта экономической составляющей, которая привела к переезду.
7 миллионов визитов в месяц, положим каждый по 10 минут. Примерно 27 активных визитов в секунду. Кажется тут надо не с GKE уезжать, а что-то оптимизировать.
В 1400usd входит обслуживание кластера deckhouse и цена обслуживания не зависит от кол-ва нод?
На самом деле зависит. По ссылке есть калькулятор, который показывает, что 10 VM входят в стоимость обслуживания сразу, а каждая последующая добавляет $20 к стоимости. Если посмотреть на красную линию на графике (а лучше не просто посмотреть, а приложить лист бумаги например;), то можно заметить, что линия переламывается и после десятой ноды цена начинает расти быстрее.
очень жаль, что не расписали как мигрировали оставшиеся сервисы - кафка и все то, что не в кубернетесе. Потому что гонять трафик через полинтернета такое себе решение.
Понятно что статейка рекламная, чтобы показать "flant deckhouse" (свой как бы дистрибьютив), но судя по всему даже нет возможности сконфигурироваться с eBPF и/ calico-cni.
Для сети у нас в планах cilium (issue).
свой как бы дистрибьютив
Почему "как бы"? Вполне себе дистрибутив. Ранчеру можно, а Фланту нельзя? Да ещё и CNCF сертификацию прошли...
Другой вопрос, что дистрибутив дистрибутиву рознь, а я просто не успел все ещё пощупать, что там ребята накодили. Но по спецификации выглядит... интересно
судя по всему даже нет возможности сконфигурироваться с eBPF и/ calico-cni.
ну, это просто говорит, что продукт пока в активной стадии разработки (Окей, можно сказать, что "сыроват", но у кого нет проблем и недоработок)
Как переехать с GKE на Deckhouse, чтобы разработчики этого даже не заметили. Кейс robota.ua