Conta le uscite del proxy separatamente dalle repliche

Tre repliche proxy dietro un unico gateway di traduzione possono comunque esporre un solo punto di uscita pubblico. Gli indirizzi privati dei container non determinano l'identità visibile a destinazione.

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

Segui il disegno in due parti. Il servizio pubblicato sceglie come un client raggiunge una replica. La rotta di uscita e il NAT scelgono l'indirizzo di origine della connessione successiva di quella replica.

La mesh di instradamento di Docker Swarm accetta traffico su una porta di servizio pubblicata e lo invia a un task attivo. Questo supporta la distribuzione dell'ingresso e le modifiche al posizionamento dei task; non assegna un'uscita pubblica distinta a ogni replica.

Se servono uscite distinte, progetta le loro rotte e i loro indirizzi reali, come host instradati separatamente o gateway di uscita assegnati, poi conta le identità in uscita osservate.

Sostituire una replica sostituisce anche i suoi flussi attivi

Un tunnel CONNECT stabilito appartiene a un solo processo proxy. Un altro task non può ricreare in modo trasparente lo stato TCP e TLS della destinazione quando sostituisce quel processo. Pianifica le riconnessioni e svuota le connessioni di lunga durata per la manutenzione.

Trasferisci anche l'autenticazione dei client e le politiche di destinazione sulle repliche. Il controllo della porta riuscito di un bilanciatore è più ristretto di un client autorizzato che negozia il protocollo proxy richiesto. Capacità, identità di uscita e sopravvivenza delle connessioni sono requisiti separati da valutare.