Telle proxy-útgongen apart fan replika's

Trije proxy-replika's efter ien oersettende gateway kinne noch altyd ien publike útgong sjen litte. Privee container-adressen bepale net de identiteit dy't by de bestimming sichtber is.

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

Folgje de tekening yn twa dielen. De publisearre tsjinst kiest hoe't in klant in replika berikt. De útgongsrûte en NAT kieze it boarne-adres fan 'e ferfolchferbining fan dy replika.

It routing-net fan Docker Swarm akseptearret ferkear op in publisearre tsjinstpoarte en stjoert it nei in aktive taak. Dat stipet ferdieling fan yngong en feroarings yn taakpleatsing; it jout net oan elke replika in aparte publike útgong.

As aparte útgongen nedich binne, ûntwerp dan har echte rûtes en adressen, lykas apart rûtearre hosts of tawiisde útgongsgateways, en tel dan waarnommen útgeande identiteiten.

It ferfangen fan in replika ferfangt ek syn libbene streams

In fêstige CONNECT-tunnel heart by ien proxy-proses. In oare taak kin de TCP- en TLS-steat fan 'e bestimming net transparant opnij meitsje as it dat proses ferfangt. Plan fernijde ferbiningen en romje langduorjende ferbiningen foar ûnderhâld.

Bring ek kliïntautentikaasje en bestimmingsbelied oer nei de replika's. In suksesfolle poartekontrôle fan in load balancer is smeller as in tastiene klant dy't it fereaske proxy-protokol ûnderhannelt. Kapasiteit, útgongsidentiteit en it oerlibjen fan ferbiningen binne aparte easken om te beoardieljen.