35 виртуалок → 2 Kubernetes-кластера: как «Лазурит» перестроил свою инфраструктуру
Клиент: «Лазурит»
Ниша: мебельный ритейл, e-commerce
Услуга: DevOps, миграция инфраструктуры, мониторинг
«Лазурит» — мебельный ритейлер с интернет-магазином и физическими точками продаж. Внутри компании работает сервисы, которые помогают обрабатывать заказы, считать сроки доставки, распределять звонки и поддерживать другие бизнес-процессы.
Задача
Инфраструктура «Лазурита» долго росла вокруг текущих задач. Сервисы жили на отдельных виртуальных машинах, рядом с ними часто лежали базы данных, часть файлов и бэкапов хранилась на одном сервере. А за мониторинг отвечал сторонний подрядчик, и доступ к метрикам проходил через его VPN.
Это создавало риски для бизнеса:
- При сбое сетевой зоны могли пострадать базы и файлы.
- При релизах сервисы останавливались на несколько минут.
- Разработчикам было сложно следить за нагрузкой на проде.
Команда KTS провела аудит и начала постепенно переводить внутренние бизнес-сервисы в новую инфраструктуру на Kubernetes.
Что получилось
- Около 35 виртуальных машин → 2 Kubernetes-кластера
Раньше под многие сервисы была отдельная виртуалка, а база данных часто жила рядом с сервисом. Сейчас внутренние сервисы работают в двух мультизональных Kubernetes-кластерах.
- 2–3 минуты простоя при релизе → релиз без полной остановки сервиса
До миграции деплой останавливал Docker-контейнеры на виртуалке. После переезда старая версия продолжает работать, пока новая не запустилась. Если релиз падает, команда получает алёрт, а прошлая версия сервиса остаётся доступной.
- Окна миграции укладывались примерно в час
Сначала команда «Лазурита» проверяла сервисы в тестовом окружении, а затем инженеры KTS переключали домены, переносили базы и перезапускали сервисы в Kubernetes. Техокно для переключения было узким, потому что менеджеры «Лазурита» работают в разных часовых поясах, и нужно было уложиться между концом рабочего дня в Калининграде и его началом во Владивостоке.
Собрали новую основу на Kubernetes
Целевую инфраструктуру построили вокруг двух мультизональных Kubernetes-кластеров. Внутренние сервисы больше не привязаны к одной виртуалке, где одновременно лежат код, база и локальные файлы.
Это было важно именно для бизнесовых сервисов. Через них просходят заказы, расчёт доставки, звонки и распределение задач между менеджерами. Когда такой сервис недоступен, проблема быстро доходит до людей, которые работают с клиентами.
Перенесли бэкапы и файловый обмен в S3
Раньше сервисы могли обмениваться файлами через примонтированные директории на нескольких виртуалках. Для старой схемы это было привычно, но в Kubernetes такой подход мешает: сервисы могут работать на разных узлах и в разных зонах.
Мы перевели бэкапы в S3. Команда «Лазурита» начала встраивать работу с S3 в PHP-сервисы, чтобы обмениваться файлами без привязки к локальной директории. Если контейнер переезжает в другую зону, он подключается к S3 и продолжает работать с теми же данными.
Упростили релизы
До проекта релиз проходил через CI/CD и Ansible. На виртуалку скачивался новый образ, старые Docker-контейнеры останавливались, после этого поднимались новые. Но даже в случае успеха сервис останавливался на две-три минуты на время переключения. А если в новой версии была ошибка, сервис мог не подняться.
После переезда в Kubernetes новая версия поднимается рядом со старой. Пока она не готова, старая продолжает обслуживать запросы. Если новая версия не запускается, приходит алёрт, а сервис остаётся на рабочей версии.
Работе менеджера это не мешает: в худшем случае страница с заказами попросит обновиться из-за разрыва старого соединения. Разработчики «Лазурита» теперь могут выкатывать сервисы днём, без ожидания вечернего окна и без полной остановки на время релиза.
Построили мониторинг для всех
Мы развернули новый мониторинг на связке VictoriaMetrics и Grafana. Команда видит графики по сервисам, базам, трафику и нагрузке, а метрики остаются внутри виртуальной сети.
Мониторинг стал полезен и разработчикам «Лазурита». Они сами заходят в Grafana, смотрят рост потребления места, нагрузку на базу и поведение сервиса во время нагрузочного тестирования. Такой подход даже помог команде разработки выявить и оптимизировать сервис, который раньше отправлял тяжелые PostgreSQL-запросы и требовал больших ресурсов.
Результаты
- Сервисы переехали с виртуалок в мультизональные кластеры Kubernetes.
- Релизы перестали требовать полной остановки сервиса.
- Разработчики получили доступ к мониторингу.
- Бэкапы и файловый обмен начали уходить в S3.
В похожих проектах мы часто начинаем с аудита. Смотрим, где сервисы привязаны к одной зоне, где база живёт рядом с приложением, как устроены бэкапы и что происходит при релизе. После этого можно двигаться по шагам: убрать самый рискованный участок, перенести сервисы, оптимизировать деплой и наладить поддержку.
Если у вас инфраструктура тоже выросла из набора виртуалок и ручных скриптов, можно начать с аудита. Мы посмотрим, где сейчас самые хрупкие места, и предложим план миграции без лишней перестройки продукта.