Я пошел вперед и использовал релиз postgres helm для установки небольшого «кластера» на локальном кластере kubernetes.установка прошла гладко - у нас есть главный экземпляр и два подчиненных, на которые реплицируются данные (единственный перезапуск, показанный ниже, в порядке, как это было сделано вручную для тестирования).
prod-postgres-postgresql-master-0 2/2 Running 0 15h
prod-postgres-postgresql-slave-0 1/1 Running 0 16h
prod-postgres-postgresql-slave-1 1/1 Running 1 9d
Эти модули поставлялись с соответствующими службами (я использую NodePort, так как нет облачного провайдера для добавления внешнего IP-адреса к LoadBalancer):
prod-postgres-postgresql NodePort 10.96.119.67 <none> 5432:31920/TCP 9d
prod-postgres-postgresql-headless ClusterIP None <none> 5432/TCP 9d
prod-postgres-postgresql-metrics ClusterIP 10.106.163.49 <none> 9187/TCP 9d
prod-postgres-postgresql-read ClusterIP 10.97.58.56 <none> 5432/TCP 9d
Используемые значениядля установки совпадают с производственными значениями в репо с небольшим изменением пароля и класса хранения (для которого я вручную предоставил необходимые PV)
Мой вопрос:
Как сделатьЯ сейчас использую это развертывание БД для чтения со всех узлов postgres?
Я понимаю, что:
- только мастер пишет
- эта диаграмма управления не предлагает никакой формы аварийного переключения после смерти мастера (скажем, модуль находится вкраш-откат по какой-то причине).
- у мастера есть собственный сервис:
prod-postgres-postgresql
- у рабов есть собственный сервис:
prod-postgres-postgresql-read
Так как сервисы разные, как я могускажите моему приложению, что ему разрешено читать больше, чем просто мастер?
Если это не поддерживается, то какова "точка" этой диаграммы управления?Наряду с отсутствием отказа, рабы кажутся бессмысленными.