RHEL 7 上で単一ノードの Kubernetes クラスターを実行しています。
Windows Server 2019 サーバーも持っています。
Windows サーバーと RHEL サーバーは両方とも同じホスト上の仮想マシンです。
RHEL のコマンド プロンプトでcurlIIS 上の URL から 500 KB のドキュメントを取得するために実行すると、要求は「高速」です (1 秒未満)。
Kubernetes ポッドで実行されているコンテナ内から同じリクエストを実行すると、リクエストは「遅い」 (4 秒以上) になります。
これは、Kubernetes ポッド ネットワーク プロバイダーとしての Calico (オリジナル) と Weave (現在は代わりにデプロイ) の両方で発生します。
コンテナ内で実行しtcpdump、HTTP 要求の過程で多数の TCP 再送信とウィンドウ サイズの更新が行われることを確認しました。
これは (私の限られた知識では) MTU 関連の問題のように見えます。ただし、IIS 側と Weave ネットワーク内の両方で MTU を減らしても効果はありませんでした。
パケットがドロップされている場所を特定できるように、IIS 側と RHEL マシンの両方で顧客が実行したパケット ダンプを待っています。
その間、どんなアイデアでも大歓迎です。
答え1
根本的な原因を100%確信することはできませんでしたが、問題は解決しました。
パケットダンプは、Weave MTUが標準の1376であったため、IISからK8sボックスに到着したジャンボフレーム（1500バイトをはるかに超える）がLinuxによって「フラグメンテーションが必要」として拒否されたことを示しました。
リンクの両端のMTUは1500でしたが、TCPセグメンテーションオフロードが機能していたのではないかと考えています（顧客はVMWareを使用しており、ゲートウェイ VM からの不可解な「フラグメンテーションが必要」拒否多少関連があるようです）
すべてが単一の VM 内にあるという理由で、Weave ネットワークに非常に高い MTU (65404) を設定することになりました。
これにより、パケットの断片化が解消され、コンテナ内からの HTTP リクエストが K8s ホストの外部からのリクエストと同じくらい高速になりました。