Tæl proxy-udgange adskilt fra replikaer

Tre proxyreplikaer bag én oversættende gateway kan stadig vise én offentlig udgang. Private containeradresser bestemmer ikke den identitet, der er synlig ved destinationen.

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

Følg tegningen i to dele. Den publicerede tjeneste vælger, hvordan en klient når en replika. Udgangsruten og NAT vælger kildeadressen for den replikas videre forbindelse.

Docker Swarms routing-mesh accepterer trafik på en publiceret serviceport og sender den til en aktiv opgave. Det understøtter fordeling af indgang og ændringer i opgaveplacering; det tildeler ikke en særskilt offentlig udgang til hver replika.

Hvis der kræves forskellige udgange, skal du designe deres reelle ruter og adresser, f.eks. særskilt rutede værter eller tildelte udgangsgateways, og derefter tælle observerede udadgående identiteter.

Udskiftning af en replika udskifter også dens aktive streams

En etableret CONNECT-tunnel tilhører én proxyproces. En anden opgave kan ikke gennemsigtigt genskabe destinationens TCP- og TLS-tilstand, når den erstatter den proces. Planlæg genforbindelser, og dræn langvarige forbindelser ved vedligeholdelse.

Overfør også klientgodkendelse og destinationspolitikker til replikaerne. En belastningsfordelers vellykkede portkontrol er snævrere end en tilladt klient, der forhandler den krævede proxyprotokol. Kapacitet, udgangsidentitet og forbindelsesoverlevelse er separate krav at vurdere.