Стоит ли запускать PostgreSQL в Kubernetes?

Если у вас нет времени читать статью, то краткий ответ: да! Запуск кластера базы данных PostgreSQL в Kubernetes — это жизнеспособный и готовый к использованию в продакшене способ хостинга баз данных. Но так было не всегда. Раньше, когда единственным примитивом Kubernetes для этого были StatefulSets, управление базами данных в кластере Kubernetes было задачей не из простых. Сейчас, благодаря зрелости специализированных операторов для Kubernetes, таких как CloudNativePG, настоящие ограничения чаще связаны с навыками и опытом инженеров, управляющих кластером.

Тем не менее, запуск PostgreSQL в Kubernetes не гарантирует повышения уровня безопасности или автоматического решения проблем с отказоустойчивостью. Однако он открывает большие возможности для автоматизации и расширяемости, которых было бы крайне сложно достичь другими средствами.

Почему именно PostgreSQL?

Да, рабочие нагрузки баз данных не ограничиваются одной PostgreSQL. MySQL, MongoDB и другие СУБД тоже имеют зрелые Kubernetes-операторы с полезными возможностями и интересными сценариями использования — про многие из них можно написать отдельные статьи. Но в этой публикации мы сосредоточимся на PostgreSQL.

Чем хороша PostgreSQL?

Вот лишь некоторые преимущества PostgreSQL:

Долговечность: Более 25 лет инноваций и развития. PostgreSQL — стабильный и проверенный временем выбор, которому доверяют многие.
Открытость и универсальность: Это многозадачная СУБД с открытым исходным кодом, которая подходит для самых разных типов нагрузок и сценариев использования.
Высокая доступность: Поддерживает архитектуру "основной–реплики" (primary–replica), где есть один ведущий (primary) и несколько реплик только для чтения. Это повышает время безотказной работы и доступность данных.
Продвинутый протокол репликации: Возможности вроде синхронной репликации (контроль на уровне транзакций) и каскадной репликации обеспечивают согласованность данных и стабильную производительность при чтении — даже между кластерами Kubernetes.
Восстановление после сбоев: Непрерывное резервное копирование и восстановление до определённой точки во времени (PITR) позволяют надёжно восстановить данные с любого момента, обеспечивая отказоустойчивость и безопасность операций.
Сильное сообщество и популярность: PostgreSQL широко используется и стабильно входит в число самых уважаемых и популярных СУБД, что делает её надёжным выбором для множества команд и проектов.

PostgreSQL в Kubernetes — хорошая ли это идея?

Если бы вы проспали десять лет и очнулись только после выхода Kubernetes v1.14, вас бы удивило, насколько изменилось мнение сообщества по поводу размещения баз данных в Kubernetes. С выходом версии v1.14 в статусе General Availability появились локальные постоянные тома (Local Persistent Volumes), и паттерн операторов и контроллеров начал активно развиваться. Этот сдвиг вызвал переоценку того, насколько уместно запускать базы данных в Kubernetes. Но прежде чем перейти к тому, почему теперь это может быть действительно хорошим решением, стоит разобраться, почему ещё недавно запуск баз в Kubernetes считался рискованным, мягко говоря.

Изначально в Kubernetes были доступны только два примитива для работы с ворклоадами: Deployments и StatefulSets. Deployments довольно быстро оказались непригодны для баз данных: они создают поды непредсказуемо, назначают случайные сетевые идентификаторы и не могут гарантировать, что конкретная реплика останется ведущей (primary). StatefulSets улучшили ситуацию: они индексируют поды, обеспечивают предсказуемое масштабирование, закрепляют постоянные сетевые имена и позволяют каждой реплике использовать собственное постоянное хранилище. Это значит, что если реплика выйдет из строя, новая сможет подключиться к тому же хранилищу, что и её предшественник.

Но как выразился Виктор Фарчич:

«Тот факт, что StatefulSet — лучшее решение по сравнению с Deployment, не делает его хорошим решением.»

Для действительно production-ready рабочих нагрузок с базами данных, StatefulSets всё ещё не обеспечивают ключевые функции, такие как:

Резервное копирование (Backups)
Автоматическое переключение в случае сбоя (Automated Failovers)
Повышение роли реплик (Replica Promotions)
Наблюдаемость (Observability)

И поскольку StatefulSets были недостаточны, многие пришли к выводу, что Kubernetes не подходит для баз данных.

Так зачем вообще запускать базы данных PostgreSQL в Kubernetes?

Потому что всё изменилось. StatefulSet — больше не единственный инструмент в арсенале. Сегодня Kubernetes воспринимается не как готовое решение «из коробки», а как высоко расширяемая платформа. Его настоящая сила именно в расширяемости.

Теперь вы можете не ограничиваться только нативным Kubernetes-хранилищем — его возможности можно расширить с помощью CSI-плагинов (Container Storage Interface). И самое главное — вместо использования только StatefulSet мы теперь имеем в распоряжении специализированные операторы, предназначенные для управления сложными, состояниезависимыми рабочими нагрузками. Эти операторы не только выполняют всё то, что раньше делал StatefulSet, но и предоставляют полный набор функций на уровне базы данных, необходимых для продакшена.

Крис Милстед из Akamai хорошо выразился:

«Когда вы переносите данные в Kubernetes, ваши проблемы с отказоустойчивостью никуда не исчезают. Вам всё так же нужно думать об этих проблемах. Но теперь делать это проще — благодаря множеству автоматизаций, которые происходят либо со стороны самого Kubernetes, либо через такие инструменты, как CloudNativePG. Это сильно упрощает путь к автоматизации — не нужно тратить на всё месяцы.»

Интегрируя слой данных в ваш кластер Kubernetes, вы получаете единое пространство для сетей и вычислений, а также доступ к Kubernetes-фичам вроде:

самовосстановления (self-healing),
распределения по зонам доступности и регионам,
и других преимуществ из коробки.

Габриэле Бартолини, вице-президент по Cloud Native в EDB и уважаемый член сообщества PostgreSQL, рекомендует запускать PostgreSQL в Kubernetes, чтобы достичь следующих ключевых преимуществ:

Репликация на уровне приложения: Использование встроенной репликации PostgreSQL для синхронизации данных внутри и между кластерами Kubernetes, вместо репликации на уровне хранилища. Такой подход нативен для Kubernetes и идеально подходит для обеспечения устойчивости приложений и согласованности состояния.
Оптимизация по зонам доступности: Использование зон доступности Kubernetes вместо разнесённых дата-центров в отдельных кластерах. Это позволяет обеспечить автоматическую высокую доступность без потерь данных и с минимальным временем восстановления (RTO) — прямо из коробки, в пределах одного региона.

Какие есть альтернативные способы?

Запуск напрямую на виртуальной машине

Конечно, так можно сделать. Особенно когда StatefulSet в Kubernetes был единственным вариантом — никто бы вас за это не осудил.

Использование управляемого сервиса баз данных вне кластера

Во многих случаях выбор между запуском PostgreSQL в Kubernetes и использованием полностью управляемого сервиса напоминает классическую дилемму: SaaS против self-hosted решений. Для многих, включая меня и нашу команду, расширяемость и гибкость, которые даёт Kubernetes, в сочетании с относительной простотой использования оператора вроде CloudNativePG, делают самостоятельный хостинг очевидным выбором.

Кроме того, высокая стоимость управляемых сервисов только облегчает решение в пользу самостоятельного размещения PostgreSQL в Kubernetes.

На сабреддите r/kubernetes это хорошо подметили в одном из комментариев:

Что нужно, чтобы запускать PostgreSQL в Kubernetes?

В целом, для эффективного управления PostgreSQL в Kubernetes требуются три основных компонента:

Экспертиза в Kubernetes: Ваша команда или организация должна хорошо разбираться в Kubernetes, чтобы уметь управлять кластером и устранять возможные проблемы.
Экспертиза в PostgreSQL: Глубокое понимание PostgreSQL необходимо для настройки, оптимизации и поддержки базы данных в среде Kubernetes.
Надёжный оператор: Используйте проверенного оператора, способного управлять полным жизненным циклом кластера PostgreSQL — обеспечивать высокую доступность, масштабирование и другие ключевые функции.

Обратите внимание:

Если вы уже запускаете приложения в Kubernetes, но храните данные вне кластера, прежде чем “перетаскивать” базу данных внутрь, обязательно проконсультируйтесь с опытным специалистом. Этот процесс далеко не тривиальный.

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

Кстати, об операторе: что такое CloudNativePG?

CloudNativePG — это оператор с открытым исходным кодом, предназначенный для управления кластерами баз данных PostgreSQL в Kubernetes. Он обладает широким набором функций, которые делают его готовым к использованию в продакшене и отлично подходящим для сценариев с высокой доступностью.

Некоторые ключевые возможности CloudNativePG:

Готовность к продакшену: Разработан для работы с реальными рабочими нагрузками.
Kubernetes-оператор: Полностью интегрирован с API Kubernetes.
Автоматическое переключение при сбое: Обеспечивает высокую доступность, автоматически переключаясь на реплику при сбое основной инстанции.
Полностью декларативный подход: Управление кластерами PostgreSQL через декларативные конфигурации.
Открытый исходный код: Бесплатный и поддерживаемый сообществом.
Самовосстановление: Обнаруживает сбои инстансов и автоматически восстанавливает базу данных.
Управление кластерами: Выполняет роль менеджера PostgreSQL-кластера в Kubernetes.
Повышенная безопасность: Поддерживает mTLS для безопасной связи между компонентами.
Оптимизированное хранилище: Разделяет хранилище для WAL-файлов.
Резервное копирование и восстановление: Встроенные функции для бэкапа и восстановления после сбоев.
Rolling-обновления: Минимизирует простои во время обновлений.
Расширенный контроллер Kubernetes: Добавляет функциональность, специфичную для PostgreSQL.
Экспорт в Prometheus: Лёгкая интеграция с системами мониторинга.
Прямое управление PVC: Использует PersistentVolumeClaims напрямую для поддержки различных типов хранилищ.
Репликация на уровне приложения: Обеспечивает согласованную репликацию данных на уровне PostgreSQL.
Плагин для kubectl: Удобное управление через CLI Kubernetes.

CloudNativePG — мощный инструмент, и как видно, он закрывает все те функциональные пробелы, которых не хватало в чистом StatefulSet.

Какое хранилище использовать?

В Kubernetes существуют два основных типа доступа к хранилищу:

Сетевое хранилище (Network Storage): Обычно реализуется через NFS, CSI-плагины или другие варианты сетевого подключения. Это наиболее часто используемый подход в Kubernetes, но он может вызывать проблемы с пропускной способностью и задержками, особенно в общих средах, где несколько приложений конкурируют за I/O ресурсы.
Локальное хранилище (Local Storage): Начиная с версии Kubernetes 1.14, стало возможным использовать локальное хранилище, напрямую подключенное к узлу, включая bare-metal-сценарии. Локальное хранилище отлично подходит для нагрузок с высокой транзакционной активностью или для очень больших баз данных (VLDB). Оно обеспечивает архитектуру «shared-nothing» с более высокой и предсказуемой производительностью, что особенно важно для приложений, требующих быстрого и стабильного доступа к данным.

Для продакшен-нагрузок наиболее предпочтительным и рекомендованным вариантом является использование локального хранилища, подключённого к хосту, где работает база данных PostgreSQL. CloudNativePG обладает высокой гибкостью: он позволяет использовать разные типы хранилищ, подключаемых через PVC (Persistent Volume Claims) — как для активных данных, так и для резервного копирования.