Использование Patroni с Kubernetes

примечание

Эта страница переведена при помощи нейросети GigaChat.

Patroni может использовать объекты Kubernetes для хранения состояния кластера и управления ключом лидера. Это позволяет ему работать с PostgreSQL в среде Kubernetes без какого-либо хранилища согласованности, а именно, нет необходимости запускать дополнительную развертку Etcd. Существует два различных типа объектов Kubernetes, которые Patroni может использовать для хранения ключей лидера и конфигурации. Они настраиваются с помощью переменной kubernetes.use_endpoints или PATRONI_KUBERNETES_USE_ENDPOINTS.

Использование конечных точек

Несмотря на то, что это рекомендуемый режим, он отключен по умолчанию из соображений совместимости. Когда он включен, Patroni хранит конфигурацию кластера и ключ лидера в полях metadata: аннотации соответствующих конечных точек, которые он создает. Изменение лидера безопаснее, чем при использовании ConfigMaps, поскольку одновременно обновляются как аннотации, содержащие информацию о лидере, так и фактические адреса, указывающие на работу под лидером.

Использование ConfigMaps

В этом режиме Patroni будет создавать ConfigMaps вместо конечных точек и хранить ключи внутри метаданных этих ConfigMaps. Для изменения лидера требуется не менее двух обновлений: одно для карты конфигурации лидера и другое для соответствующей конечной точки.

Чтобы направить трафик на ведущий PostgreSQL, необходимо настроить службу Kubernetes PostgreSQL для использования селектора меток с role_label (настроено в конфигурации Patroni).

Обратите внимание, что в некоторых случаях, например, при запуске на OpenShift, нет альтернативы использованию ConfigMaps.

Конфигурирование

Настройки Patroni Kubernetes и переменные среды описаны в общих главах документации.

Настройка метки роли

По умолчанию Patroni устанавливает соответствующие метки на под, в котором он работает, основываясь на роли узла, например, role=master. Ключ и значение метки могут быть настроены с помощью kubernetes.role_label, kubernetes.leader_label_value, kubernetes.follower_label_value и kubernetes.standby_leader_label_value.

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

1. Добавьте временную метку, используя исходное значение роли для пода с помощью kubernetes.tmp_role_label (как tmp_role). После перезапуска подов они получат следующие метки, установленные Patroni:

   labels:
     cluster-name: foo
     role: master
     tmp_role: master

2. После обновления всех подов измените селектор службы для выбора временной метки.

   selector:
     cluster-name: foo
     tmp_role: master

3. Добавьте свою пользовательскую метку роли (например, установите kubernetes.leader_label_value=primary). После перезапуска подов они получат следующие новые метки, установленные Patroni:

   labels:
     cluster-name: foo
     role: primary
     tmp_role: master

4. После того, как все поды будут обновлены снова, измените селектор службы для использования нового значения роли:

   selector:
     cluster-name: foo
     role: primary

5. Наконец, удалите временную метку из своей конфигурации и обновите все поды.

   labels:
     cluster-name: foo
     role: primary

Примеры

• Папка kubernetes репозитория Patroni содержит примеры образа Docker и манифеста Kubernetes для тестирования настройки Patroni Kubernetes. Обратите внимание, что в текущем состоянии он не сможет использовать постоянные тома из-за проблем с разрешениями.
• Полнофункциональный образ Docker, который может использовать Persistent Volumes, можно найти в проекте Spilo.
• Существует также диаграмма Helm, чтобы развернуть изображение Spilo, настроенное с помощью Patroni, работающее с использованием Kubernetes.
• Чтобы запускать кластеры баз данных в масштабе с использованием Patroni и Spilo, взгляните на проект postgres-operator. Он реализует шаблон оператора для управления кластерами Spilo.