Стоит ли запускать базы данных в Docker и Kubernetes
Продвинутое4 минРедакция Innovialabs
Коротко
Docker отлично подходит для баз в локальной разработке и CI; в продакшене небольшим командам обычно лучше managed-база, а запуск в Kubernetes окупается только со зрелым оператором и людьми, которые умеют его эксплуатировать.
Коротко
Для разработки и тестов — да: база в Docker за секунды даёт всем одинаковую версию. Для продакшена вопрос не в том, «умеют ли контейнеры запускать базы» (умеют), а в том, «кто будет заниматься хранилищем, бэкапами, failover и обновлениями в три часа ночи».
- Нет выделенных DevOps-инженеров: берите managed-базу у облачного провайдера.
- Уже работаете в Kubernetes и хорошо его знаете: зрелый оператор вроде CloudNativePG — разумный выбор.
- Промежуточный вариант: база на отдельной виртуальной машине, возможно в Docker, с автоматическими и проверенными бэкапами.
Что действительно важно
Производительность хранилища. Базы чувствительны к задержкам диска. Сетевые тома удобны, но медленнее локальных NVMe-дисков. Локальные тома быстрые, но привязывают pod к одной ноде: если нода умрёт, восстановление зависит от репликации, а не от переподключения диска. Тестируйте конкретный storage class на своей нагрузке.
Сохранность. Данные должны лежать на томе, а не в записываемом слое контейнера. В Kubernetes используйте StatefulSet или оператор с PersistentVolumeClaim и настройте reclaim policy так, чтобы удаление claim не удаляло данные молча.
Бэкапы. Нужны и регулярные полные копии, и непрерывное архивирование журналов транзакций для point-in-time recovery, причём храниться они должны вне кластера, например в объектном хранилище. Бэкап, который ни разу не восстанавливали, — это надежда, а не бэкап: планируйте тестовые восстановления.
Failover. Один pod с базой — единая точка отказа. Для высокой доступности нужны реплики, автоматический выбор лидера и клиенты, которые переподключаются к новому primary. Это самая сложная часть для самостоятельной сборки и главная причина существования операторов.
Зрелость оператора. Оператор кодирует знания DBA: репликацию, failover, бэкапы, минорные обновления. Для PostgreSQL есть несколько устоявшихся вариантов, включая CloudNativePG, postgres-operator от Zalando и Crunchy PGO; Percona поддерживает операторы для MySQL, PostgreSQL и MongoDB. Смотрите на активность проекта, документацию, как устроены обновления и восстановление и использовал ли его кто-то в команде в продакшене.
Ресурсы. Аккуратно задавайте memory requests и limits: если контейнер превысит лимит памяти, его убьют, а для базы это падение и восстановление. Не размещайте базы рядом с шумными нагрузками.
Managed против self-hosted
| Фактор | Managed-база | Self-hosted в Kubernetes |
|---|---|---|
| Усилия на запуск | Низкие | От средних до высоких |
| Бэкапы и PITR | Встроены | Настраиваются через оператор |
| Failover | Делает провайдер | Делает оператор, отвечаете вы |
| Контроль и расширения | Ограничены провайдером | Полные |
| Переносимость, on-prem | Привязка к провайдеру | Одинаковая схема везде |
| Из чего складывается стоимость | Размер инстанса, хранилище, трафик | Ноды, хранилище, время инженеров |
Время людей — статья расходов, о которой забывают чаще всего. Self-hosted кластер, который экономит на счёте, но требует постоянного внимания, редко оказывается дешевле.
Схема выбора
По размеру команды:
- 1–5 разработчиков без DevOps: managed-база. Docker Compose — только для локальной разработки и CI.
- Команда с одним-двумя DevOps-инженерами: по умолчанию managed-база; self-hosted — для некритичных и внутренних систем или когда данные должны оставаться на определённом оборудовании или в определённой стране.
- Платформенная команда со множеством сервисов: оператор в Kubernetes позволяет стандартизировать десятки баз — с runbook, мониторингом и регулярными учениями по восстановлению.
По нагрузке:
- Чувствительный к задержкам OLTP с большим количеством записей: выделенные ноды с быстрым локальным хранилищем или managed-сервис с гарантированными IOPS.
- Preview-окружения, тесты, временные стенды: база в Kubernetes идеальна, данные не жалко.
- Кэши и очереди (Redis и подобные): проще запускать в контейнерах, особенно если данные можно восстановить.
- Большие аналитические нагрузки: обычно место на специализированных сервисах или выделенных машинах.
Частые ошибки
- Данные хранятся внутри контейнера, а не на томе.
docker compose down -vна сервере удаляет именованные тома вместе с данными.- Deployment с одной репликой вместо StatefulSet или оператора.
- Бэкапы лежат в том же кластере или на том же диске, что и база.
- Порты базы открыты в интернет.