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

client → published service → proxy replica → egress/NAT → destination

Разберите схему на две части. Опубликованный сервис выбирает, как клиент попадает на реплику. Маршрут выхода и NAT выбирают адрес источника дальнейшего соединения этой реплики.

Маршрутная сеть Docker Swarm принимает трафик на опубликованном порту сервиса и отправляет его активной задаче. Это поддерживает распределение входа и изменения размещения задач; она не назначает каждой реплике отдельный публичный выход.

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

Замена реплики заменяет и её активные потоки

Установленный туннель CONNECT принадлежит одному процессу прокси. Другая задача не может прозрачно воссоздать состояние TCP и TLS пункта назначения, когда заменяет этот процесс. Планируйте переподключения и при обслуживании опорожняйте долгоживущие соединения.

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

Похожие статьи