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

примечание

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

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

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

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

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

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

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

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

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

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

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

По умолчанию Patroni установит соответствующие метки на под, в котором он запущен, на основе роли узла, например role=primary. Ключ и значение метки можно настроить с помощью параметров 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: primary
     tmp_role: primary

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

   selector:
     cluster-name: foo
     tmp_role: primary

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

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

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

   selector:
     cluster-name: foo
     role: primary

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

   labels:
     cluster-name: foo
     role: primary

Примеры

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