プロキシ出口はレプリカとは別に数える

翻訳ゲートウェイ 1 つの背後にプロキシレプリカが 3 つあっても、公開出口は 1 つのままになり得ます。コンテナのプライベートアドレスは、宛先で見える同一性を決めません。

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

図は 2 つの部分に分けて追います。公開サービスが、クライアントがレプリカにどう到達するかを選びます。出口ルートと NAT が、そのレプリカの後続接続の送信元アドレスを選びます。

Docker Swarm のルーティングメッシュは、公開サービスポートでトラフィックを受け取り、稼働中のタスクへ送ります。これは入口の分散とタスク配置の変更を支えますが、各レプリカに別々の公開出口を割り当てるものではありません。

別々の出口が必要なら、個別にルーティングされたホストや割り当て済みの出口ゲートウェイなど、実際のルートとアドレスを設計し、そのうえで 観測される外向きの同一性 を数えます。

レプリカの置き換えは稼働中のストリームも置き換える

確立済みの CONNECT トンネルは 1 つのプロキシプロセスに属します。そのプロセスを置き換えるとき、別のタスクが宛先の TCP と TLS の状態を透過的に再現することはできません。再接続を計画し、保守のために長寿命接続を排出します。

クライアント認証と宛先ポリシーもレプリカ間で引き継ぎます。ロードバランサのポートチェック成功は、必要なプロキシプロトコルを交渉する許可済みクライアントより狭い範囲です。容量、出口の同一性、接続の維持は別々に評価すべき要件です。