Хабр, привет!
В этой статье я расскажу вам о PostgreSQL и его работе внутри кластера Kubernetes. Краткое превью того, о чем мы поговорим: как появился PostgreSQL, какие у него фреймворки High Availability, как обеспечивается отказоустойчивость внутри Kubernetes и какие операторы Kubernetes существуют. 
Для наглядности и обзора возможных случаев будут приведены примеры схем, приступим!
Для погружения — (очень) краткая история PostgreSQL.
PostgreSQL был выпущен с открытым исходным кодом Университетом Беркли в 1996 году.В течение следующих двух лет его работа стабилизировалась и развивалась базовая функциональность.
Тогда возник вопрос: как сделать эту систему совместимой со стандартным SQL? А уже в 1998 году началась разработка самого ядра.
Позже возникла необходимость в развитии возможностей уровня предприятия.
Одной из таких функций, о которой мы подробно поговорим ниже, является потоковая репликация.
Именно это лежит в основе отказоустойчивости PostgreSQL, и без этого эта статья не существовала бы.
Потоковая репликация
Он появился в 2010 году с выпуском PostgreSQL 9.0. Прошло более 10 лет, однако ни один релиз до сих пор не включил в себя стандартные механизмы переключения между мастером и репликой.Это может вызвать различные проблемы.
Давайте посмотрим, как они выглядят в типичных случаях.
Случай №1 – идеальный (без потери данных) Здесь все просто: у нас есть мастер и реплика, полностью синхронизированная с мастером.
В какой-то момент мы «осторожно» останавливаем мастер и переводим в режим ожидания новый мастер.
В результате мы продолжаем корректно работать без потери данных.
Случай №2 более проблематичен (часть данных потеряна)
Представим, что у нас работал мастер, но по каким-то причинам он дал сбой, и часть данных не успела «дойти» до дежурного режима.
Мы решаем сделать резервным нового мастера.
При этом теряется небольшая часть данных, которые не успели передаться с мастера на резерв.
Случай №3 – самый неприятный (расщепление мозга)
В данном случае у нас тоже есть мастер и резервный, но в какой-то момент, скажем, мастер перестал быть доступен по сети.
И мы решили активировать режим ожидания записи и сделать его мастером.
Но теперь мастер снова в строю, он работает, и мы находимся в ситуации, когда в системе одновременно находятся два мастера, и приложение также может записывать данные на оба мастера.
Проблема в том, что нам как-то нужно собрать все данные обратно в один мастер, но обычно это становится очень сложно сделать.
А если помимо этого у вас есть какая-то сложная структура данных, то сделать это становится практически невозможно.
Эту ситуацию обычно называют расщеплением мозга.
Есть ли решение?
Здесь мы не забываем, что PostgreSQL — продукт с открытым исходным кодом и его можно улучшать.Сторонние компании разработали свои утилиты для обеспечения высокой доступности и автоматического переключения между главным и резервным режимами.
Самые популярные из них:
- Коросинк/кардиостимулятор.
С помощью Corosync мы можем объединить несколько серверов в один кластер, а Pacemaker позволяет нам управлять PostgreSQL как одним из сервисов внутри кластера.
- Столон.
Создает дополнительные компоненты, такие как прокси, который является точкой входа для пользователей и приложений, кипер, который управляет PostgreSQL, и дозорный, который, в свою очередь, управляет кипером и прокси.
- репмгр.
Утилита для управления репликацией и переключениями с использованием встроенного протокола репликации PostgreSQL.
- Патрони.
На мой взгляд, самый интересный продукт. В отличие от других продуктов и утилит, Patroni представляет собой шаблон для обеспечения высокой доступности PostgreSQL. В качестве компонентов для обеспечения той или иной функциональности могут использоваться различные решения, что весьма положительно влияет на гибкость и возможность настройки конструкции высокой доступности.
Поэтому это Предлагаю вам присмотреться к патрони .
Знакомство с Патрони
Патрони показал себя вожаком стада, который со временем показал себя самым сильным и выносливым слоном.
Эта утилита теперь является фактическим стандартом обеспечения высокой доступности PostgreSQL. 
Давайте подробнее рассмотрим архитектуру утилиты: у нас есть серверы, на которых установлен PostgreSQL. Они связаны друг с другом посредством потоковой репликации.
Рядом с PostgreSQL установлен Patroni, который может управлять PostgreSQL — останавливать, запускать, перезапускать, автоматически создавать и пересоздавать резервные, если это необходимо.
Теперь появляется следующий компонент — DCS (система распределенного консенсуса).
Уже из названия понятно, что эта система нужна для обеспечения консенсуса.
С помощью DCS мы можем четко определить, где находится наш хозяин.
А если у нас с ним возникнут проблемы, то этот компонент позволяет нам выбрать нового мастера и продолжить с ним работу.
Компоненты DCS могут включать в себя: etcd, протокол raft, Kubernetes, Zookeeper, обратные вызовы aws и т. д. Для нас наиболее интересны первые три.
- и т. д.: это распределенное хранилище ключей-значений, объединенное в кластер.
Его можно установить как на автономные серверы, так и на серверы, где PostgreSQL уже установлен вместе с Patroni.
- протокол плота: Замечу, что сам etcd работает по протоколу raft, а с выходом Patroni 2.0 появилась возможность не устанавливать всю базу данных etcd, а использовать чистый протокол raft. Это значительно упрощает работу решения и позволяет использовать на один компонент меньше.
- Кубернетес: Этот компонент — именно то, что нам нужно для развертывания Patroni внутри кластера Kubernetes, у которого уже есть собственная база данных etcd. Используя вызовы API к этой базе данных etcd, мы можем обеспечить консенсус в нашем кластере Patroni.
Еще одна составляющая – Балансировщик нагрузки , это необязательно в архитектуре Patroni. Может быть полезно для балансировки нагрузки на основном или резервном сервере.
Другой случай использования балансировщика нагрузки — необходимость единой точки входа в наши базы данных PostgreSQL. Вы всегда можете подключиться к тому же IP, который, в свою очередь, уже будет привязан к серверу, на котором находится наш мастер.
Внутри Райффайзенбанка как балансировщика нагрузки для Patroni мы используем vip-менеджер .
Глядя на такую архитектуру, с высокой доступностью и отказоустойчивостью, возникла идея — а что, если переместить ее в Kubernetes?
Реализуем наши планы: кластер PostgreSQL внутри Kubernetes
Механизмы обеспечения высокой доступности
Начнем с контроллеров — Развертывание , позволяет управлять приложениями без сохранения состояния и StatefulSet , позволяет управлять приложениями с отслеживанием состояния.Возможно, непонятно, что означают эти слова.
Поясню на примерах.
Приложения без сохранения состояния - приложения, которым не нужно хранить свое состояние.
Самый популярный пример приложения без сохранения состояния — веб-сайт. Ему не обязательно сохранять свое состояние.
Размещаешь его как деплой внутри Kubernetes, и он прекрасно масштабирует нагрузку при необходимости: нагрузка увеличилась — создал дополнительное количество подов, чтобы справиться со всей возросшей нагрузкой на сайт. Приложения с отслеживанием состояния.
Они уже должны копить свое состояние.
Самый популярный пример приложения с отслеживанием состояния — база данных.
Следующий механизм – PodAntiAffinity , который нужен для того, чтобы поды не размещались на одних и тех же серверах или, например, на одних и тех же серверах.
Таким образом мы обеспечиваем высокую доступность.
Представим, что есть поды с базами данных, и если они все расположены на одном сервере и возникают проблемы с сервером, то база данных станет недоступна, и в этой ситуации переключить мастер базы данных на другой уже будет невозможно.
pod, так как доступного модуля, на который можно переключить мастер, просто не будет. PodDisruptionБюджет также используется для обеспечения высокой доступности.
Этот механизм определяет в единицах или процентах количество модулей, которые могут быть недоступны в определенный момент времени.
Опять же явно стоит задача — перевести два сервера в режим обслуживания.
Поды, работающие на этих серверах, будут недоступны.
Kubernetes должен решить эту проблему.
Что делаем: устанавливаем PodDisruptionBudget в размере одной штуки.
И, соответственно, в данной ситуации сначала мы переместим один под на другой сервер.
Мы ждем, когда он станет доступен.
И теперь второй под тоже переедет на другой сервер.
Приложение продолжит работать корректно.
Хранилище данных
Один из вариантов — хранить данные на сетевом блочном устройстве.Сетевое блочное устройство.
В нашем случае в кластере Kubernetes мы создаём StatefulSet с базой данных.
Kubernetes может создавать диски для модулей из сетевого блочного устройства на основе шаблона.
Соответственно, оттуда были выделены диски и присоединены к подам, и наш StatefulSet стал работать корректно.
Теперь представьте, что один из серверов кластера k8s стал недоступен, и под тоже станет недоступен.
В такой ситуации под переедет на другой сервер, а затем, поскольку мы используем сетевое блочное устройство, диск будет переназначен другому поду.
Наш StatefulSet с базой данных продолжит успешно работать.
Есть еще один вариант размещения данных – локальное хранилище непосредственно на серверах.
Здесь мы также можем создать StatefulSet. Если сервер станет недоступен, то под больше не сможет переместиться на другой сервер из-за того, что диски привязаны непосредственно к серверу, на котором запущены поды.
А нам нужно будет починить сервер и разобраться, что случилось.
Операторы Кубернетеса
Познакомимся с наиболее популярными операторами, существующими для запуска PostgreSQL внутри Kubernetes. Хрустящие данные У этого оператора есть лицензия Apache 2.0, поэтому при желании вы можете использовать этот продукт бесплатно.Если поддержка необходима, ее можно приобрести за определенную плату.
Кстати, одним из плюсов является то, что этот продукт поддерживается в Kubernetes, OpenShift и VMware PKS. Ну а ключевой особенностью этого и других операторов Kubernetes (о которых мы поговорим дальше) является то, что компонент Patroni используется для обеспечения высокой доступности самого PostgreSQL. Так что это фактический стандарт обеспечения высокой доступности как внутри Kubernetes, так и на обычных серверах.
Стэкгрес Особенность этого оператора в том, что он поставляется по лицензии AGPLv3. Лицензия имеет ряд ограничений, и Stackgres позволяет их обойти.
Например, если вы используете в своем проекте продукт с AGPLv3, то весь исходный код производного продукта также должен быть выпущен под той же лицензией.
И исходный код также должен быть открыто опубликован.
Postgres-оператор Zalando Еще один интересный оператор Kubernetes. И вот почему: Zalando — это компания, которая разработала Patroni, и в качестве продолжения своего развития они написали этого оператора, чтобы их продукт также мог работать на кластерах Kubernetes. Zalando имеет лицензию MIT, которая позволяет использовать этот продукт бесплатно.
Но здесь ребята не предоставляют платную поддержку, и если вы решите ею воспользоваться, то вам нужно будет поддерживать ее самостоятельно.
Все три оператора Kubernetes предоставляют возможность использовать графическую утилиту, которая открывается в вашем браузере.
Утилита также позволяет просматривать журналы состояния и работы вашего кластера, клонировать, редактировать некоторые параметры или даже удалять кластеры PostgreSQL.
Также стоит отметить, что Crunchy Data и Stackgres имеют встроенные инструменты для мониторинга PostgreSQL, которых, к сожалению, нет в postgres-operarot от Zalando.
Вкратце: плюсы и минусы размещения базы данных PostgreSQL внутри Kubernetes.
Почему удобно разрабатывать:- база данных «живет» рядом с приложением
- сокращение времени выхода на рынок
- полный переход на методологию CI/CD
- загруженным базам данных нужны быстрые диски
- «шумные соседи»: здесь нужно ограничить использование ресурсов подами
- дополнительная задержка сети внутри Kubernetes задерживает базу данных
Зная все нюансы, вы сможете успешно использовать базу данных внутри Kubernetes! > > > В этой статье я поделился основными моментами и добавил новые подробности из доклада на конференции code/R IT. Смотрите в прямом эфире и слушайте все выступление можно найти здесь .
Теги: #Kubernetes #базы данных #Администрирование баз данных #postgresql #DevOps
-
Прокладка L2-Туннелей В Openvpn
19 Oct, 24 -
Ictf 2008 — Сформирован Список Участников
19 Oct, 24 -
Трейлер К Запуску Metal War Online
19 Oct, 24
