Как выбрать главный модуль Redis в этом примере Kubernetes?

Вот пример, по которому я смоделировал.

В разделе Readme "Удалить наш модуль руководства":

  1. Сами часовые redis понимают, что мастер исчез из кластера, и начинают процедуру выбора нового мастера. Они выполняют этот выбор и выбор и выбирают одну из существующих реплик сервера Redis в качестве нового мастера.

Как выбрать нового мастера? Все 3 серверных модуля Redis, управляемые redis контроллером репликации из redis-controller.yaml, по-прежнему имеют одинаковые

labels:
  name: redis

это то, что я сейчас использую в своей Службе для их выбора. Как 3 модуля будут различаться, чтобы я из Kubernetes знал, какой из них главный?


kubernetes docker node.js redis redis-sentinel
person writofmandamus    schedule 16.03.2017    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Как будут различаться 3 модуля, чтобы я из Kubernetes знал, какой из них главный?

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

redis-cli info

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

redis-cli info | grep ^role
Output:
role: Master

Обратите внимание, что Replication controllers заменяются на Deployments для служб без отслеживания состояния. Для сервисов с отслеживанием состояния используйте Statefulsets.

person Farhad Farahi    schedule 16.03.2017
comment
Спасибо. Чтобы избежать простоев, нужно ли мне каким-то образом настроить Sentinel (или найти какой-то перехватчик) для автоматического обновления основного модуля (возможно, добавив метку role: master в дополнение к текущей метке name: redis) и создать другую службу, которая выбирает name:redis и role: master )? В противном случае мое приложение не сможет делать запросы на запись, пока я не получу уведомление о сбое сервера Redis и не зайдусь поиском мастера вручную. - person writofmandamus; 16.03.2017
comment
Вам не нужно этого делать, развертывания / наборы репликации автоматически запустят другой экземпляр базового модуля при сбое модуля (выход / сбой узла), чтобы расширить эту возможность, вы можете использовать зонды живости и повторяемости для проверки микросервиса (служба в контейнере). ) здоровья через определенные промежутки времени, и если контейнер неисправен, он автоматически перезапустится. - person Farhad Farahi; 16.03.2017
comment
Извините, я не понимаю. Прямо сейчас мой контроллер репликации (скоро будет StatefulSet / Deployment) действительно автоматически запускает другой экземпляр (как описано в руководстве). Однако проблема в том, что (возвращаясь к моему первоначальному вопросу) Kubernetes не знает, какой из них (новый модуль или существующие репликации) является главным. Вы предложили мне вручную войти в каждый контейнер и использовать redis-cli для проверки ролей. Итак, мой последующий вопрос был вместо того, чтобы вручную, как это можно сделать автоматически (например, моя служба по-прежнему может точно выбрать главный модуль). - person writofmandamus; 16.03.2017

arrow_upward
3
arrow_downward

Ваша клиентская библиотека Redis действительно справится с этим. Например, с ioredis:

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

Итак, вы фактически подключаетесь к redis-sentinel вместо redis-client.

person writofmandamus    schedule 29.03.2017

arrow_upward
0
arrow_downward

Нам нужно сделать то же самое и попробовать разные вещи, например, изменить диаграмму. Наконец, только что создал простой докер python, который выполняет маркировку, и создал диаграмму, которая предоставляет мастер redis как службу. Это периодически проверяет созданные поды для redis-ha и маркирует их в соответствии с их ролью (главный / подчиненный).

Для поиска ведущего / ведомого устройства используются те же команды-дозорные.

helm chart redis-pod-labeler здесь исходный репозиторий

person Manoj Prasanna    schedule 19.07.2019