問題タブ [docker-ingress]

Windows Server 2019 でオーバーレイ ネットワークを使用したルーティング メッシュのサポートについて言及している投稿をいくつか見つけました (以下の参考文献を参照)。

多くのトラブルシューティングを行った結果、次のネットワークとサービスを使用して作成されたユーザー定義のオーバーレイ ネットワークで 2 つの単純なコンテナーを適切に構成できません。

ポート 80 で Docker ホストを参照すると、iis Web サイトにアクセスできますが、他のコンテナーが同じオーバーレイ ネットワーク上にある場合pingweb、メイン コンテナーに ping を送信できません。web

また、pingweb コンテナーがオーバーレイ ネットワーク上にある場合は常に、外部サイトに ping を実行できないことにも気付きました。ping をテストしましたが、ネットワーク上のコンテナーにping を実行しようとしているときと8.8.8.8同じ結果になるため、オーバーレイ ネットワークで実行すると機能しません。Request timed outwebtestnet

質問:

1. これは既知の問題ですか?
2. どうすればこれを機能させることができますか?

参考文献:

https://docs.microsoft.com/en-us/virtualization/community/team-blog/2017/20170926-docker-s-routing-mesh-available-with-windows-server-version-1709

https://www.docker.com/blog/docker-windows-server-1709/

Windows での Docker イングレス モード サービスの公開

Linux サービスの公開オプションと同等であることは、Windows のお客様から強く要望されています。Windows Server 1709 でイングレス モードを使用したサービス公開のサポートを追加すると、Docker のルーティング メッシュを使用できるようになり、サービスのタスクを実行しているノードに関係なく、外部エンドポイントが swarm 内の任意のノードを介してサービスにアクセスできるようになります。

これらのネットワークの改善により、オーバーレイ ネットワークの使用時に VIP ベースのサービス ディスカバリのロックも解除されるため、Windows ユーザーは DNS ラウンド ロビンに制限されなくなります。

改善点の詳細については、Microsoft Virtualization ブログの対応する投稿を確認してください。

Ubuntu-14 と Mac (Big Sur) の 2 台のラップトップがあり、どちらにも Docker (swarm サポートあり) がインストールされています。

• Swarm マネージャーとして Ubuntu を使用し、ワーカー ノードとして Mac を使用しました。
• Ubuntu プライベート IP は 192.168.0.14 (および) Mac プライベート IP は 192.168.0.11 です [すべてのクラス C ネットワークが同じ IP を持っているため、プライベート IP は問題なくパブリックで共有できます:P]
• 「docker swarm init --advertise-addr」は、Ubuntu ホストであるマネージャーを作成するために使用したコマンドであり、Mac で join コマンドを入力して、Mac ノードを Swarm にワーカーとして参加させました。

したがって、大まかに言うと、docker-compose.yml (Python Web サービスが 1 つしかない) を使用しました。Compose ファイルを使用して、「docker スタック」を開始し、「python webservice」インスタンスを 5 に複製しました。これらのアクションはすべて Manager ノードで実行されました。

• Ubuntu Manager Node (同じく 2 つのコンテナー インスタンスがあり、ワーカーとして動作) (および) Mac Node には、「python webservice」の 3 つのコンテナー インスタンスがありました。「ポート」を「80:1234」に設定しました。つまり、ホスト マシンのポート 80 にアクセスすると、コンテナ内で実行されている 1234 の「python アプリケーション Web サービス ポート」にリダイレクトされます。

• Manager IP (192.168.0.14:80) を約 50 回ヒットし、Mac と Ubuntu の両方で 5 つのコンテナーすべてのログを確認したところ、Ubuntu で 2 つのコンテナーすべてが見つかり、それぞれ 25 ヒットを取得しました (ラウンドで) robin fashion) しかし、Mac マシンに存在するコンテナーのログは見つかりませんでした。

これは予期される動作ですか?

1. Mac マシン (ワーカー) の IP アドレス (192.168.0.11:80) を直接ヒットした場合にのみ、Mac マシンに存在するコンテナーのログ/リクエスト ヒットを取得できました。

ここでは 2 種類の負荷分散が行われます。

1. (ワーカー/マネージャーの) IP:port にアクセスすると、そのワーカー/マネージャー マシンに存在するコンテナーのみが負荷分散され、ラウンドロビン方式で提供されます (使用されているアルゴリズムであることがわかります)。この負荷分散タイプを「コンテナ レベルのロード バランサー」と名付けましょう。

2. しかし、192.168.0.14 (マネージャー IP) に達したとき、2 つのノードにデプロイされた 5 つのコンテナーすべてで負荷が分散されると予想しました。どういうわけかこれはうまくいきませんでした。「ノードレベルのロードバランサー」と呼びましょう

私はこれについてグーグルでたくさん検索しようとしましたが、何も見つかりませんでした。ほとんどのサイトは、「ノード レベルのロード バランサー」を解決するために、Nginx、HaProxy ロード バランサーなどの外部テクノロジを使用しています。

ドッカー自体による、これに対するすぐに使えるサポートはありませんか?

EDIT 1 - Metin がコメント セクションで尋ねたので、docker-compose.yml を追加しました

docker-compose.yml

401,402, 403..etc HTTP ステータス応答が auth-url から受信されたときはいつでも、400 イングレスがクライアントに正しく認証応答を送信していますが、500 内部サーバー エラーとして送信され、クライアントに認証応答が返されない 400 不正な要求入力の場合*

入力ファイル、ログ、応答を見つけてください

入力ファイル

イングレス ログ

401,402, 403..etc HTTP ステータス応答が auth-url から受信された場合は常に、400 イングレスを除いてクライアントに auth 応答が適切に送信されますが、400 Bad Request イングレスの場合は 500 Internal Server Error として送信され、クライアントに auth 応答が返されません。

応答：