Tel proxy-utgangar skilt frå replikaer

Tre proxyreplikaer bak ein omsetjande gateway kan framleis visa éin offentleg utgang. Private containeradresser avgjer ikkje identiteten som er synleg ved destinasjonen.

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

Følg teikninga i to delar. Den publiserte tenesta vel korleis ein klient når ein replika. Utgangsruta og NAT vel kjeldeadressa til den vidare sambindinga til den replikaen.

Rutingsnettet til Docker Swarm tek imot trafikk på ein publisert tenesteport og sender han til ein aktiv oppgåve. Det støttar fordeling av inngang og endringar i oppgåveplassering; det tildeler ikkje kvar replika ein eigen offentleg utgang.

Viss det trengst særskilde utgangar, design dei reelle rutene og adressene deira, til dømes separat ruta vertar eller tildelte utgangsgatewayar, og tel deretter observerte utgåande identitetar.

Å byta ut ein replika bytar òg ut dei levande straumane hans

Ein etablert CONNECT-tunnel høyrer til éin proxyprosess. Ein annan oppgåve kan ikkje gjennomsiktig attskapa TCP- og TLS-tilstanden til destinasjonen når han byter ut den prosessen. Planlegg attkoplingar og tøm langvarige sambindingar for vedlikehald.

Overfør òg klientautentisering og destinasjonspolitikkar til replikaene. Ein vellukka portkontroll frå ein lastbalanserar er snevrare enn ein tillaten klient som forhandlar den påkravde proxyprotokollen. Kapasitet, utgangsidentitet og overleving av sambindingar er separate krav å vurdera.