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

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

Розгляньте схему в двох частинах. Опублікований сервіс вибирає, як клієнт потрапляє на репліку. Маршрут виходу та NAT вибирають адресу джерела подальшого з'єднання цієї репліки.

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

Якщо потрібні окремі виходи, спроєктуйте їхні реальні маршрути й адреси, наприклад окремо маршрутизовані хости або виділені вихідні шлюзи, а потім рахуйте спостережувані зовнішні ідентичності.

Заміна репліки замінює і її активні потоки

Установлений тунель CONNECT належить одному процесу проксі. Інше завдання не може прозоро відтворити стан TCP і TLS пункту призначення, коли замінює цей процес. Плануйте перепідключення та під час обслуговування спорожнюйте довготривалі з'єднання.

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

Схожі статті