Docker Compose вместо Kubernetes: когда простота выигрывает

Когда я рассказываю коллегам, что в одном из рабочих проектов мы сознательно не стали переезжать на Kubernetes и остались на Docker Compose, реакция обычно одна и та же: удивлённо поднятые брови. Постараюсь объяснить логику этого решения.

Контекст проекта

Речь о внутреннем сервисе для одной команды из шести человек: один API, одна база данных, один воркер для фоновых задач и nginx перед всем этим. Нагрузка предсказуемая, пиков нет, серьёзного масштабирования не требуется — сервис используют около двухсот сотрудников компании в рабочее время.

Что предлагал Kubernetes

На бумаге всё звучало правильно: автоматическое восстановление после падения, встроенный service discovery, декларативные манифесты, единая экосистема для будущего роста. Но каждый из этих плюсов идёт в комплекте со стоимостью — и не только денежной.

Kubernetes требует отдельной экспертизы для эксплуатации: обновления кластера, настройка RBAC, управление сетевыми политиками, мониторинг самого кластера как отдельной системы. Для команды, где нет выделенного DevOps-инженера, это означает, что кто-то из разработчиков должен взять на себя эту роль — а это время, отнятое от продуктовой разработки.

Что мы выбрали вместо этого

Один сервер, Docker Compose, systemd-юнит, который следит, чтобы docker compose up запускался при перезагрузке хоста. Обновление — через CI, который собирает образ и перезапускает контейнеры по SSH. Бэкапы базы — по расписанию в S3-совместимое хранилище. Мониторинг — Prometheus с несколькими алертами в Telegram.

Вся эта конфигурация умещается в один docker-compose.yml на полторы сотни строк, который понятен любому новому разработчику в команде за десять минут чтения.

Когда это решение перестанет работать

Я честно держу в голове границы этого подхода. Если понадобится масштабировать конкретный компонент независимо от остальных, если появится необходимость в zero-downtime деплое с несколькими репликами, или если команда вырастет настолько, что понадобится самообслуживание инфраструктуры для нескольких проектов сразу — это будет сигналом пересмотреть решение.

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