Я хочу привести к следующей проблеме.
Мое понимание:
Docker swarm включает в себя вход и DNS-сервер, который идентифицирует службы по их именам. Он также включает в себя встроенные надежные балансировщики нагрузки на каждом узле кластера. Мы можем поразить любую службу, работающую на разных узлах, которые участвуют в режиме скопления докеров, используя IP-адрес любой машины. Если на компьютере не размещена служба, балансировщик нагрузки направит запрос на другой компьютер, на котором размещена эта служба. Для лучшей практики мы можем выбрать контейнер балансировщика нагрузки (NGINX/HAProxy) в качестве обратного прокси-сервера для маршрутизации запросов на основе некоторых предопределенных алгоритмов (циклический перебор/хэш/IP-хэш/наименьшее соединение/наименьшая пропускная способность и т. д.) .
Постановка проблемы:
Я хочу создать кластер из двух/трех разных машин, где я буду развертывать все необходимые технические службы. Мини-среда контроля качества.
Поскольку служба идентифицируется по имени, я не могу создать другую службу с таким же именем. Будучи разработчиком, я хочу, чтобы служба работала на моем локальном хосте, который также является частью кластера docker swarm. Очевидно, я не могу назвать его таким же. Итак, допустим, я назову его как myIP_serviceName. Теперь запись DNS, которую имеет рой докеров, будет основана на этом имени.
Мне нужен механизм, в котором, если я вызову какую-либо службу, используя свой IP-адрес в качестве хоста, балансировщик нагрузки будет искать любую службу, которая зарегистрирована в DNS как myIP_serviceName, и если она найдет какую-либо службу с таким именем, вызов должен быть направлен на этой службы, если это не так, вызов должен следовать по обычному пути. Это должно сохраняться для каждого последовательного запроса, который является частью пути туда и обратно.
Я еще не изучил Kubernetes. Пожалуйста, предложите, можно ли здесь использовать Kubernetes для более элегантного достижения этой цели.
Пожалуйста, исправьте мое понимание, если я ошибаюсь, и дайте ценные предложения.
