Два Kubernetes-кластера вместо 35 виртуалок: как мы перестроили инфраструктуру Лазурита

Продолжаем рассказывать про DevOps-проекты. Сегодня делимся историей крупного мебельного ритейлера «Лазурит».

Инфраструктура компании годами росла вокруг текущих бизнес-процессов: обработки заказов, распределения звонков, расчёта сроков доставки. Сервисы жили на отдельных виртуальных машинах, рядом лежали базы данных, бэкапы хранились на одном сервере. За мониторинг отвечал подрядчик, и доступ к метрикам шёл через его VPN.

Такая инфраструктура создавала риски: при сбое сетевой зоны могли пострадать данные, а релизы останавливали сервисы на несколько минут. Менеджеры не могли работать с заказами, а разработчики тратили время на ручную диагностику.

DevOps-команда KTS провела аудит и постепенно построила новую отказоустойчивую инфраструктуру:

🌟перевели бизнес-сервисы в Kubernetes: теперь они работают в двух мультизональных кластерах, мониторятся через новый стек и поддерживаются командой KTS; 🌟убрали простой при релизах: после переезда старая версия сервиса функционирует, пока новая не запустилась; 🌟перенесли бэкапы и файловый обмен в S3 и исключили привязку к локальной директории: если контейнер переезжает в другую зону, он подключается к хранилищу и продолжает работу с теми же данными; 🌟развернули новый мониторинг на VictoriaMetrics-стеке: у разработчиков «Лазурита» теперь есть прямой доступ к дашбордам по сервисам, базам, трафику и нагрузке. Это не заменяет сопровождение, но закрывает много мелких вопросов, которые раньше отнимали время.

Подробнее о том, как построили новую инфраструктуру на Kubernetes и упростили релизы, читайте в кейсе