Как следует использовать приложения с использованием активной/пассивной избыточной модели с использованием кубернетов?

Question

У меня есть распределенное приложение, работающее на виртуальных машинах, среди которых у меня есть одна служба, работающая в активном/пассивном режиме. Активная виртуальная машина предоставляет услугу через публичный IP-адрес. В случае сбоя активной виртуальной машины публичный IP-адрес будет перемещен в пассивную виртуальную машину, и пассивная виртуальная машина станет активной и начнет предоставлять услугу.

Как этот шаблон подходит для контейнерных приложений, управляемых кубернетами?

Если я использую контроллер репликации с репликами = 1, в случае сбоя узла/миньона контроллер репликации перепланирует pod (= VM в моем текущем приложении) в другом миньоне, но это, вероятно, приведет к большому времени простоя по сравнению с мое текущее решение, в котором перемещается только IP-ресуремент.

Если я использую контроллер репликации с replicas = 2, тогда мне нужно будет иметь другую конфигурацию с двумя контейнерами (один с открытым IP-адресом, а другой без), который является анти-шаблоном? Более того, в кубернетах не предусмотрено никакого способа поддерживать виртуальный IP (перемещать струи aroud.)?

ИЛИ следует использовать replicas = 2 и реализовать что-то самостоятельно для управления IP (или, возможно, использовать кардиостимулятор?), Это вызовет еще одну проблему: в моем приложении будут использоваться кузнецы и кардиостимулятор/corosync)

так, как это должно быть сделано?

Answer 1

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

Это может быть достигнуто сегодня в Кубернете, используя сервис, который охватывает оба контейнера (главный и резервный) и зонд готовности, который только возвращает успех для текущего активного мастера. Неисправность зонда готовности удаляет контейнер из списка конечных точек, поэтому трафик не будет направлен на узел, который не является ведущим. Когда вам нужно выполнить переход на другой ресурс, резервный режим будет сообщать о здоровом состоянии зонда готовности (и хозяин будет сообщать о нездоровой ситуации или быть недостижимой), в результате чего трафик на службу будет приземляться только в режиме ожидания (теперь он действует как ведущий).

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