Как переехать с GKE на Deckhouse, чтобы разработчики этого даже не заметили. Кейс robota.ua

Robota.ua — сервис для поиска вакансий и сотрудников в Украине. Включает в себя веб-сайт со средней посещаемостью 7 млн визитов в месяц и приложения для iOS и Android. Мы помогаем robota.ua поддерживать кластеры Kubernetes.

Кейс интересен тем, что за короткое время клиенту удалось бесшовно переехать с Google Kubernetes Engine (GKE) на другой managed-сервис. Расскажем о ключевых этапах проекта, немного об экономике и о том, какие возможности для развития и кастомизации инфраструктуры появились у robota.ua*.

Технологический стек

Robota.ua используют в основном Open Source-решения. Для разработки большей части сервисов — .NET; в качестве хранилищ — реляционные и документные БД (в зависимости от решаемой задачи). Общение между сервисами обеспечивает Kafka, а доступ к ним организован через федеративный GraphQL. Фронтенд написан на Angular и размещается в большом монорепозитории. 

Инфраструктура до перезда

До лета 2021 года основная часть инфраструктуры robota.ua размещалась в европейском дата-центре Google. Старые части системы — на собственных серверах в Украине. Большинство сервисов запускалось в GKE.

Почему использовался именно managed-сервис?

У ИТ-команды robota.ua не было опыта работы с Kubernetes, поэтому managed-сервис стал самым рациональным способом кубернетизировать приложения. И такой выбор оправдал себя: по словам CTO Александра Марченко, за все то время, что команда пользовалась GKE, с Kubernetes не было ни одного инцидента: он просто работал. Подход хорош и тем, что разработчики не вникали в сложности устройства Kubernetes, а фокусировались на своей основной деятельности — разработке.

Почему отказались от Google

Основная причина — в росте стоимости managed Kubernetes. В 2018-м, в самом начале кубернетизации, у robota.ua было меньше сервисов, небольшие prod- и тестовое окружения. Некоторое время ценник был приемлемым. Но со временем стоимость тестовых окружений стала обходиться в такую же сумму, что и prod. Количество сервисов, которые развернуты в managed K8s, увеличивалось. В итоге было решено мигрировать в частное облако украинского провайдера и найти альтернативу GKE.

У robota.ua был положительный опыт с managed Kubernetes от Google, и они хотели получать такую же услугу в другом облаке. Такая позиция совпадает с трендом индустрии: недавно мы рассказывали об исследованиях, которые подтверждают, что всё больше компаний выбирают managed Kubernetes у провайдеров или готовые платформы. Причины тренда детально разобрал Дмитрий Столяров в своем докладе «Как правильно сделать Kubernetes».

«Нам нужно было решение, которое бы, с одной стороны, не стоило, как крыло от самолета, а с другой, позволяло бы держать одинаковые кластеры».

Александр Марченко

CTO robota.ua

Тогда robota.ua обратились к нам. С учетом того, что инфраструктура была уже в K8s, они увидели перспективу в managed Kubernetes на базе платформы Deckhouse, которая предлагает готовые к работе кластеры Kubernetes. Большой бонус в том, что такой Kubernetes можно использовать, в частности, поверх любых виртуальных машин (ВМ).

На решение robota.ua повлияло и то, как работает техподдержка «Флант». Мы на связи 24х7 и всегда готовы помочь. Тем более в таком сложном деле, как переезд, который Бенджамин Франклин сравнивал с пожаром.

Переезд

Новую инфраструктуру было решено развернуть в частном облаке украинского провайдера Colocall (Киев). Kubernetes-кластеры запускались на базе платформы Deckhouse, которая работает поверх статических ВМ Colocall. 

Нужно было перенести 100+ сервисов (deployment’ов), многие из которых работали под нагрузкой в production. Основную часть команда robota.ua перенесла за две недели; в целом же переезд занял полтора месяца.

Robota.ua используют отдельную continuous delivery-систему Octopus Deploy. Поэтому первым делом было настроено развертывание приложений через систему в новый кластер. При миграции проблем не возникло, так как кластеры Kubernetes под управлением Deckhouse — это, по сути, «ванильный» Kubernetes. Единственное, что нужно было сделать, — поменять kubeconfig в CI-системе.

Все приложения — stateless. Kafka и БД запущены не в Kubernetes и не затрагивались при переезде, настраивать миграцию данных не требовалось. Поэтому далее процесс выглядел достаточно просто и типично:

• выкатили приложение в новый кластер;

• проверили, что приложение работает;

• переключили DNS на новый кластер;

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

Перенос консьюмеров Kafka стал еще более простой задачей: достаточно было выкатить консьюмеры в новый кластер, и они сразу же взялись за работу.

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

Итог

Команда robota.ua самостоятельно и легко справилась с переездом. Мы лишь развернули и поддерживали кластеры, консультировали по вопросам работы с Deckhouse.

«Полет нормальный, Кубер живет своей жизнью. Любопытный факт: многие сервисы стали работать шустрее (теперь всё чуть ли не в соседних стойках живет)... В общем, очень круто. Честно говоря, думал, что переезд будет сильно дольше и больнее. Ведь по сути, мы тут за две-три недели из ничего сделали кластера и бесшовно переехали. Если бы не писал нашим ребятам, никто бы даже не заметил».

Александр Марченко

CTO robota.ua

Как удалось сэкономить

На момент миграции стоимость ресурсов в приватном облаке Colocall была в несколько раза ниже, чем у Google. Хотя сейчас по количеству worker-узлов и совокупной емкости CPU и RAM кластер больше того, что был в GKE, затраты на инфраструктуру и ее обслуживание снизились.

Чтобы измерить экономическую выгоду от переезда, нужно понять, как формируется итоговая стоимость кластера K8s с учетом затрат на ресурсы.

В GKE стоимость за сам Kubernetes символическая; основные затраты приходятся на виртуальные машины для кластера. Вот как распределяется бюджет:

• 73 USD в месяц — за сам кластер (здесь и далее все цены указаны без НДС);

• 255 USD — за один worker-узел с параметрами e2-standard-8 с 50 GiB Zonal standard PD в регионе europe-central2.

В расчет стоимости Managed Kubernetes от «Флант» включаем затраты на ВМ от Colocall. В общем получается:

• 1400 USD в месяц — за базовый кластер (production-кластер от Managed Deckhouse на статических ВМ без доступа к API облака);

• 153 USD — за три ВМ для управляющего слоя (Control Plane);

• 61 USD — за один worker-узел идентичной GKE конфигурации.

Теперь используем эти данные, чтобы показать, как меняются совокупные затраты на один Kubernetes-кластер с увеличением количества worker-узлов**:

На графике видно, что стоимость кластера в GKE на старте ниже. Но чем больше worker-узлов в кластере, тем дороже становится managed-сервис в целом.

Важная оговорка. Понятно, что GKE — это лишь часть огромной экосистемы Google Cloud. Она дает широкие возможности, решает большой объем задач, у нее высокая отказоустойчивость. Разные проекты используют эти возможности по-разному. В случае robota.ua команде нужен был только «голый» GKE, без дополнительных managed-сервисов — например, БД или мониторинга от Google. Поэтому миграция на другое решение managed Kubernetes оказалась целесообразной и простой. Однако в других случаях при оценке экономической эффективности переезда стоит учитывать все нюансы.

Технические плюсы

1. Более низкая latency. Сервисы robota.ua переехали из Европы в Украину, то есть ближе к основной аудитории. Это снизило задержку (latency) в общей сложности на 100 мс. Особенно явным эффект был у сервисов, время ответа у которых раньше составляло ~ 100 мс. В результате выиграли все — и пользователи, и сами сервисы.

2. Более функциональный K8s. По сравнению с KaaS-сервисами наш Managed Deckhouse подразумевает более широкую функциональность и гибкое управление кластером:

• Вместе с ​​«ванильным» Kubernetes пользователь получает преднастроенные модули для мониторинга, автомасштабирования, балансировки трафика и безопасного доступа. В случае KaaS все эти модули нужно устанавливать и настраивать самому.

  Пример

  Изначально robota.ua хотели настроить сбор логов в Loki с помощью Promtail. Но мы предложили более удобное решение, реализованное в Deckhouse, — модуль log-shipper. Сбор логов в модуле конфигурируется через создание Custom Resource с понятным и простым интерфейсом.

• Большинство провайдеров в рамках managed-услуги отвечают только за компоненты управляющего слоя и обновляют только его; обновление остальных компонентов — на пользователе. Deckhouse же полностью управляет кластером и автоматически обновляет все его компоненты. При этом доступны разные каналы обновления.

• Можно использовать внешнюю аутентификацию и авторизацию. Поддерживается OIDC.

Подробнее о возможностях платформы.

3. Независимость от поставщика ресурсов. Применительно к robota.ua одно из главных преимуществ, которое дает Deckhouse, — независимость от провайдера. Клиент может развернуть те же самые кластеры в любом облаке или на собственных серверах.

Заключение

Крупные зарубежные провайдеры отдают managed Kubernetes практически даром, основные расходы приходятся на ВМ. Когда кластер растет, можно сэкономить: например, переехать на более дешевые ВМ других провайдеров. Это позволяют платформы вроде Deckhouse. Пользователи такой платформы не занимаются низкоуровневым администрированием Kubernetes, а получают готовый API — по аналогии с тем, как это происходит в GKE, AKS или EKS. Такой вариант снижения затрат подходит, если нет другой привязки к сервисам крупного провайдера или когда понятно, как эту привязку преодолеть (пример — кейс нашего клиента Adapty).

В случае с robota.ua миграция прошла быстро и незаметно и для разработчиков, и для пользователей.

«Всегда, когда есть возможность использовать managed Kubernetes, именно его и нужно использовать».

Александр Марченко

CTO robota.ua

P.S.

Читайте также в нашем блоге:

• «Как мы помогли cybersport.ru справиться с The International 10»;

• «Переехать в Kubernetes и платить за инфраструктуру вдвое меньше? История Adapty»;

• «Опыт миграции инфраструктуры клиента из AWS в Яндекс.Облако».