Какова обычная практика управления внешним IP-адресом роя докеров?
Я создаю рой докеров из 3 менеджеров и 2 рабочих. В рое работает служба, предоставляющая порт 80. Таким образом, мы можем задействовать службу с любым IP-адресом узла. Но что, если узел выйдет из строя? Ожидать, что пользователь всегда будет пробовать IP другого узла, было бы очень обременительно.
Итак, какова общая практика управления этой внешней точкой доступа? Я могу подумать о настройке записи DNS для возврата IP-адресов нескольких узлов. Настроить еще один балансировщик нагрузки впереди кажется излишним.
Я вижу здесь несколько вариантов:
1) внешний балансировщик нагрузки.
Если вы работаете на AWS, GCE или других облачных провайдерах, вы можете использовать балансировщик нагрузки как услугу, предоставляемую этими компаниями. Ваши DNS-имена будут указывать на IP-адрес балансировщика нагрузки, и ваш балансировщик нагрузки пересылает трафик на ваши узлы.
ЗА: у вас всегда высокая доступность (балансировщик нагрузки избыточен, вам нужно как минимум 2 узла, и все готово) . Вы также получаете автоматическое переключение при отказе (если узел выходит из строя, запросы перенаправляются на другие узлы вашего кластера).
МИНУСЫ: балансировщики нагрузки стоят денег
2) «Сделай сам» балансировщик нагрузки.
Вы можете запустить другой сервер с haproxy, nginx или любой другой прокси-службой, которая запускает для вас службу балансировки нагрузки. DNS будет указывать на прокси-сервер (который на данный момент только один) и перенаправляет на ваши узлы.
ЗА: ограниченные дополнительные расходы (прокси может даже быть одним из узлов вашего кластера).
Минусы: вам нужно настроить всю инфраструктуру (переключение при отказе, обнаружение узлов, и это лишь две вещи, о которых вам следует позаботиться). Вы теряете высокую доступность (пока вы не делаете свой прокси-сервер избыточным, но я упрощаю)
3) несколько записей DNS.
Вы можете установить, как вы предложили, несколько IP-адресов в своем Записи DNS. В этом случае клиент будет подключаться к случайному узлу в вашем кластере.
ЗА: бесплатно
Минусы: если узел выходит из строя, клиенты все равно будут пытаться подключиться к нему, пока вы этого не сделаете. удалите его из своего DNS (а это требует времени из-за TTL).
Если у кого-то есть другие идеи, я рад услышать