Финтех и ЭДО
SberCorus
Релизы были редкими и ручными, каждый выкат превращался в событие.
- Перевели сервисы в Kubernetes с обновлениями без простоя
- Собрали пайплайны сборки, тестов и деплоя по окружениям
- Навели порядок в секретах и правах доступа
Внедрение Kubernetes без остановки сервисов
Переводим сервисы в Kubernetes: упаковываем приложения в контейнеры, разворачиваем кластер, настраиваем автоскейлинг, деплой и обновления без простоя. Но сначала честно проверяем, нужен ли он вам.
Ответит инженер, а не менеджер, — в течение рабочего дня.
- Сначала проверяем, нужен ли Kubernetes
- Перенос сервисов по одному
- Helm и Terraform — в вашем репозитории
- Работают инженеры-сооснователи
Официальные партнёры облаков
- Yandex Cloud
- Selectel
- Timeweb Cloud
symptoms.log
Когда к нам приходят
Релизы с простоем
Каждое обновление требует окна обслуживания, и выкатывать изменения часто страшно.
Нагрузка идёт пиками
Под пики держите запас серверов, который большую часть времени простаивает.
Окружения не похожи друг на друга
На тесте работает, в production — нет, потому что серверы настраивались вручную и по-разному.
Сервисов становится много
Десяток приложений на виртуальных машинах сложно обновлять, масштабировать и держать в одном стиле.
scope.md
Что входит в работу
Оценка готовности
Kubernetes нужен не всем. Смотрим на архитектуру, нагрузку и команду и говорим, окупится ли он — или правильный ответ проще.
Контейнеризация приложений
Пишем Dockerfile и Helm-чарты, выносим конфигурацию и секреты из образов, настраиваем health-checks.
Развёртывание кластера
Managed Kubernetes в облаке или кластер на своём железе и bare-metal — описанный кодом. Мастера и узлы — в нескольких зонах доступности, чтобы потеря зоны не останавливала кластер.
Деплой и GitOps
Пайплайны сборки и выкатки, ArgoCD, стратегии обновления без простоя и быстрый откат.
Автоскейлинг и ресурсы
Горизонтальное масштабирование подов и узлов под реальную нагрузку, лимиты и запросы ресурсов.
Наблюдаемость и безопасность
Метрики, логи и алерты кластера и приложений, RBAC, сетевые политики, управление секретами.
Что остаётся у вас
- Кластер и всё окружение описаны кодом (Terraform, Helm)
- Пайплайны деплоя для каждого сервиса
- Мониторинг кластера и приложений с дашбордами и алертами
- Документация и обучение вашей команды
Стек
- Kubernetes
- Docker
- Helm
- ArgoCD
- Terraform
- Service Mesh
- Prometheus
- Vault
git log --cases
Похожие задачи, которые мы решали
EdTech
Otus
Нагрузка идёт пиками — в дни запуска курсов, — а платить за постоянный запас мощности не хотелось.
- Перенесли инфраструктуру в облако поэтапно, без остановки сервиса
- Настроили автоматическое масштабирование под пиковую нагрузку
- Подключили мониторинг и регулярный пересмотр затрат
AI-платформы
JedAI
ML-нагрузки требуют другой инфраструктуры, чем обычные веб-сервисы.
- Развернули кластеры под задачи обучения и инференса
- Сделали окружения воспроизводимыми
- Собрали пайплайны выкатки моделей
TEAM.md
Кто будет работать над задачей
Нас трое, и это осознанно: с вами общаются и работают одни и те же инженеры, без прослойки менеджеров и передачи задач по цепочке.
Александр Калошин
Основатель
Более 20 лет в IT. В 2014 основал Last.Backend — свой оркестратор контейнеров появился практически одновременно с Kubernetes.
- Last.Backend: управление контейнерами и DevOps как сервис
- Отказоустойчивая инфраструктура: Kubernetes, CI/CD, bare-metal
- Разработка на Go
- Спикер ProIT Fest и GolangConf
Александр Тихомиров
Основатель
7 лет в DevOps, десятки реализованных проектов — от первого пайплайна до production под нагрузкой.
- Проектирование и сопровождение инфраструктуры
- Миграции в облако и построение с нуля
- CI/CD, Kubernetes, Infrastructure as Code
Денис Герасимов
Основатель
5 лет в DevOps. Берёт самые сложные задачи и доводит их до конца.
- Сложные инфраструктурные проекты
- Мониторинг, дежурства и разбор инцидентов
- Автоматизация эксплуатации
FAQ.md
Частые вопросы
- Нужен ли нам Kubernetes?
- Не всегда. Он окупается, когда сервисов много, нагрузка неравномерная, а релизы частые. Для одного-двух приложений часто достаточно контейнеров на виртуальных машинах и нормального CI/CD. Это мы выясняем на оценке до начала работ.
- Managed Kubernetes или свой кластер?
- В облаке почти всегда выгоднее managed-кластер: управляющие узлы и обновления берёт на себя провайдер. Свой кластер имеет смысл в закрытых контурах, на bare-metal и при особых требованиях к данным.
- Сколько занимает внедрение Kubernetes?
- Зависит от количества сервисов и их готовности к контейнерам. Оценку и план даём после аудита, который занимает 3–5 рабочих дней. Переводим сервисы поэтапно, без остановки работы.
- Справится ли наша команда с Kubernetes после внедрения?
- Передаём документацию и проводим обучение. Если своей экспертизы пока нет, можем остаться на сопровождении кластера.
- Что нужно от нашей команды?
- Человек, который знает систему и может ответить на вопросы, доступы с минимально необходимыми правами и согласованные окна для переключений. Остальное делаем мы.
- Не окажемся ли мы зависимы от вас?
- Нет. Код инфраструктуры, доступы и документация лежат в вашем репозитории с первого дня, аккаунты в облаке оформлены на вас. До доступа к инфраструктуре подписываем NDA, по ходу работы передаём знания вашей команде.
- Как восстановить кластер, если он потерян целиком?
- Манифесты хранятся в Git, состояние и тома копируются Velero в хранилище вне кластера, а сам кластер описан в Terraform. Поэтому его можно поднять заново, в том числе у другого провайдера.
Обсудим вашу задачу
Опишите, что происходит с инфраструктурой сейчас, — ответим в течение дня и предложим бесплатный разбор.