我有一个在 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 主机外部的请求一样快。