Tel proxy-uitgangen apart van replica's

Drie proxyreplica's achter één vertalende gateway kunnen nog steeds één publieke uitgang tonen. Privé-containeradressen bepalen niet de identiteit die bij de bestemming zichtbaar is.

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

Volg de tekening in twee delen. De gepubliceerde service kiest hoe een client een replica bereikt. De uitgangsroute en NAT kiezen het bronadres van de vervolgverbinding van die replica.

Het routing-mesh van Docker Swarm accepteert verkeer op een gepubliceerde servicepoort en stuurt het naar een actieve taak. Dat ondersteunt verdeling van de ingang en wijzigingen in taakplaatsing; het kent niet aan elke replica een afzonderlijke publieke uitgang toe.

Als afzonderlijke uitgangen nodig zijn, ontwerp dan hun echte routes en adressen, zoals apart gerouteerde hosts of toegewezen uitgangsgateways, en tel vervolgens waargenomen naar buiten zichtbare identiteiten.

Een replica vervangen vervangt ook zijn actieve streams

Een gevestigde CONNECT-tunnel hoort bij één proxyproces. Een andere taak kan de TCP- en TLS-status van de bestemming niet transparant opnieuw maken wanneer die dat proces vervangt. Plan herverbindingen en tap langdurige verbindingen af voor onderhoud.

Draag ook clientauthenticatie en bestemmingsbeleid over naar de replica's. Een geslaagde poortcontrole van een loadbalancer is smaller dan een toegestane client die het vereiste proxyprotocol onderhandelt. Capaciteit, uitgangsidentiteit en het voortbestaan van verbindingen zijn afzonderlijke eisen om te beoordelen.