Брои изходите на прокси отделно от репликите

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

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

Следвайте схемата на две части. Публикуваната услуга избира как клиентът достига до реплика. Маршрутът за изход и NAT избират адреса на източника на следващата връзка на тази реплика.

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

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

Замяната на реплика заменя и нейните живи потоци

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

Пренасяйте клиентската автентикация и политиките за дестинации и към репликите. Успешната проверка на порт от балансировчик е по-тясна от разрешен клиент, който договаря необходимия прокси протокол. Капацитетът, идентичността на изхода и оцеляването на връзката са отделни изисквания за оценка.