프록시 출구를 복제본과 별도로 세기

하나의 번역 게이트웨이 뒤에 있는 프록시 복제본 세 개도 여전히 하나의 공용 출구만 노출할 수 있습니다. 사설 컨테이너 주소는 목적지에서 보이는 정체성을 결정하지 않습니다.

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

그림을 두 부분으로 나누어 따라가세요. 게시된 서비스는 클라이언트가 복제본에 도달하는 방식을 선택합니다. 출구 경로와 NAT는 그 복제본의 이후 연결의 원본 주소를 선택합니다.

Docker Swarm의 라우팅 메시는 게시된 서비스 포트에서 트래픽을 받아 활성 태스크로 보냅니다. 이는 진입 분산과 태스크 배치 변경을 지원하지만, 각 복제본에 별도의 공용 출구를 할당하지는 않습니다.

별도의 출구가 필요하다면 별도로 라우팅된 호스트나 지정된 출구 게이트웨이처럼 실제 경로와 주소를 설계한 다음, 관찰된 외부 정체성을 세세요.

복제본을 교체하면 활성 스트림도 교체된다

설정된 CONNECT 터널은 하나의 프록시 프로세스에 속합니다. 다른 태스크는 그 프로세스를 교체할 때 목적지의 TCP 및 TLS 상태를 투명하게 재현할 수 없습니다. 재연결을 계획하고 유지보수를 위해 장기 연결을 비우세요.

클라이언트 인증과 목적지 정책도 복제본 전체로 전달하세요. 로드 밸런서의 성공적인 포트 검사는 필요한 프록시 프로토콜을 협상하는 허용된 클라이언트보다 좁은 범위입니다. 용량, 출구 정체성, 연결 유지는 별도로 평가해야 하는 요구 사항입니다.