我有一個在 RHEL 7 上運行的單節點 Kubernetes 叢集。
我還有一台 Windows Server 2019 伺服器。
Windows 和 RHEL 伺服器都是同一台主機上的虛擬機器。
當我坐在 RHEL 上的命令提示字元中並運行curl以從 IIS 上的 URL 獲取 500kb 文件時，該請求「很快」（不到 1 秒）。
當我從 Kubernetes pod 中運行的容器內部運行相同的請求時，該請求「很慢」（4 秒或更長）。
Calico（原始）和 Weave（現在部署）作為 Kubernetes Pod 網路提供者都會發生這種情況。
我已經tcpdump在容器內運行並確定在 HTTP 請求過程中存在大量 TCP 重傳和視窗大小更新。
（據我有限的知識）這看起來像 MTU 相關的問題。然而，減少 IIS 端和 Weave 網路內的 MTU 並沒有幫助。
我正在等待來自在 IIS 端和直接在 RHEL 計算機上運行的客戶的資料包轉儲，因此我可以確定資料包被丟棄的位置。
同時，任何想法都非常受歡迎。
答案1
我們已經解決了這個問題，儘管我們從未 100% 確定根本原因。
封包轉儲顯示巨型幀（遠大於 1500 位元組）從 IIS 到達 K8s 盒子，然後被 Linux 拒絕並“需要碎片”，因為 Weave MTU 是標準的 1376
鏈路兩端的 MTU 為 1500，但我們認為 TCP 分段卸載可能正在發揮作用（客戶使用 VMWare 和網關虛擬機器神秘地「需要碎片」拒絕聽起來有些相關）
我們最終在 Weave 網路上設定了非常高的 MTU - 65404 - 其基礎是它全部位於單一虛擬機器內，那麼為什麼不呢？
這解決了封包碎片問題，而來自容器內部的 HTTP 請求現在與來自 K8s 主機外部的請求一樣快。