Как развернуть базу данных в Kubernetes: StatefulSet, диски и резервные копии

База данных в Kubernetes живёт по другим правилам, чем сайт или приложение. Кластер Kubernetes это группа серверов под общим управлением, под это единица запуска из одного или нескольких контейнеров. Данные базы должны пережить пересоздание контейнера, поэтому они лежат на постоянном томе (диске, который переживает пересоздание), а не внутри пода. Когда копий базы больше одной, вместо Deployment (контроллера, который поддерживает заданное число одинаковых копий без привязки к диску) берётся StatefulSet, который закрепляет за каждой копией постоянное имя и собственный диск. PostgreSQL, MySQL и другие СУБД с собственной репликацией строятся в кластере на связке из StatefulSet, постоянных томов, репликации (копирования данных между копиями базы) средствами самой СУБД и расписания резервных копий.

Есть и второй путь: вообще не запускать СУБД внутри кластера Kubernetes, а взять управляемый сервис и подключаться к нему из приложений по внутренней сети. Оба пути рабочие. Разница в том, кто обслуживает базу данных: ваша команда или облако.

Что я наблюдаю на проектах. Выбор пути чаще всего упирается в людей. Если в команде есть инженер, который любит СУБД и готов отвечать за реплики и восстановление, свой StatefulSet даёт полный контроль. Если такого человека нет, управляемая база снимает с команды настройку репликации, переключения на реплику и прогон восстановления.

Путь первый, своими манифестами

Путь второй, управляемый сервис

В Cloud Databases кластер PostgreSQL, MySQL и других СУБД создаётся из личного кабинета: выбираете версию, конфигурацию и диски, а резервное копирование включается на этапе создания. У PostgreSQL есть ещё мультизональная конфигурация с репликами по зонам доступности, независимым площадкам региона (инструкция). Приложения из Kubernetes подключаются по внутренней сети по адресу и учётным данным.

Как выбрать путь:

1. Нужны свои параметры СУБД, которых нет в настройках управляемого сервиса, свои расширения, полный контроль: StatefulSet.

2. База нужна как данность, а время хочется тратить на продукт: управляемый сервис.

3. Рабочее сочетание, которое я вижу чаще всего: боевая база в Cloud Databases, тестовые окружения в кластере.

На схеме ниже оба пути рядом: StatefulSet с копиями db-0, db-1, db-2 и диском у каждой, стрелка резервных копий в объектное хранилище, а второй половиной тот же набор приложений ходит в управляемый кластер Cloud Databases. Репликация между db-0, db-1 и db-2 на схеме подразумевается настроенной средствами СУБД, сама по себе из трёх подов она не появится.

Пять ошибок с базами в кластере

1. Три копии ради надёжности без репликации. StatefulSet с replicas: 3 поднимает три пода, и каждый думает, что он единственная база. Приложение пишет в одну, читает из другой, данные расходятся. Число копий увеличивается только после настройки репликации в самой СУБД.

2. Временное хранилище вместо диска. Контейнер без PersistentVolumeClaim пишет в собственную файловую систему, которая исчезает вместе с ним. Проверка простая: удалите под и посмотрите, на месте ли данные, тест занимает одну команду kubectl delete pod и находит ошибку до того, как в базе появились боевые данные.

3. Политика удаления тома по умолчанию. PersistentVolumeClaim отделяет жизненный цикл данных от пода, но не от самого запроса на том. При политике Delete удаление PVC удаляет и диск. Для боевых данных берите класс хранения с политикой Retain. В Managed Containers (сервисе управляемого Kubernetes в VK Cloud) такие классы есть у каждого типа диска (хранилище в кластере).

4. Резервная копия рядом с базой. Дамп на том же диске или в том же кластере пропадёт вместе с ними при удалении тома или аварии хранилища. Копии уходят в объектное хранилище, расписание проверяется по датам файлов в бакете, именованном хранилище файлов.

5. Непроверенное восстановление. Копия, из которой ни разу не разворачивались, остаётся предположением. Прогон восстановления на тестовом окружении вносится в расписание наравне со снятием копий.

Короче говоря для заметки:

1. Данные сохраняет постоянный том, а StatefulSet добавляет копиям постоянные имена и собственные диски, этим он и отличается от Deployment.

2. Репликацию, переключение и восстановление настраивает сама СУБД или оператор, StatefulSet только поднимает поды.

3. Резервные копии выгружаем за пределы кластера и проверяем восстановление, том от удаления PVC и ошибок миграции не спасает.

4. Если база нужна без обслуживания, Cloud Databases отдаёт кластер с репликами и копиями из личного кабинета. Выбор пути решают люди: есть инженер по СУБД, берите StatefulSet, нет, берите управляемый сервис.