MTU不一致导致大包静默丢包，本质是容器网络层MTU超过路径最小MTU；需通过ping测试定位实际路径MTU，统一在CNI（如Calico/Flannel/Cilium）或Docker配置中设为1450，并在Pod中通过NET_ADMIN权限+启动脚本显式设置，最后验证ip link输出及业务连通性。
在 Kubernetes 集群中，Docker 容器（尤其是 Windows 容器或使用 bridge/overlay 网络的 Linux Pod）因 MTU 不一致导致大包丢弃，本质是容器网络层 MTU > 路径最小 MTU（如宿主机网卡、VXLAN 封装、云平台虚拟网卡、CNI 插件隧道开销等），触发静默丢包——小包（如 ping、HTTP 明文）正常，TLS 握手、大文件上传、gRPC 流式响应却频繁超时或中断。
确认是否真为 MTU 问题
别跳过这步，很多“网络故障”其实是其他原因：
- 进目标 Pod 执行：ping -M do -s 1472 8.8.8.8（1472 + 28 字节头 = 1500）。无响应或提示 “Packet too big” → 路径 MTU < 1500
- 逐步减小 -s 值（1420 → 1372 → 1320），找到最大能通的值，加 28 得出实际路径 MTU（例如 1420+28=1448 → 取整为 1450）
- 查宿主机物理网卡：ip link show eth0 | grep mtu（常见云环境为 1450 或 1400）
- 查 CNI 网络配置：如 Calico 的 IPPool、Flannel 的 BackendType 和 VNI 开销，确认其推荐 MTU（常为 1450 或 1430）
- 看内核日志：dmesg | grep "too long"，出现 “dropped packet, size 1514 > 1450” 是铁证
统一设置 Pod 网络 MTU（推荐全局方案）
让所有新建 Pod 自动继承正确 MTU，避免逐个配置：
- Calico 用户：编辑 IPPool 对象，添加 mtu: 1450 字段（需匹配底层网络），然后 kubectl apply
- Flannel 用户：修改 ConfigMap kube-flannel-cfg 中的 net-conf.json，增加 "MTU": 1450，重启 flanneld DaemonSet
-
Cilium 用户：通过 Helm values 设置 global.devices.
.mtu=1450 ，或用 CiliumClusterwideNetworkPolicy 控制 - 若使用 Docker 作为运行时（非 containerd），确保 /etc/docker/daemon.json 有 {"mtu": 1450} 并重启 dockerd（影响节点上所有容器）
为特定 Deployment/Pod 显式指定 MTU
适用于测试验证、多租户混跑或 CNI 不支持全局 MTU 的场景：
- 在容器 securityContext 中添加 NET_ADMIN 权限（必需）
- 通过环境变量传入 MTU 值，并在容器启动脚本中执行：ip link set eth0 mtu $MTU
- Kubernetes YAML 示例片段：
image: dockurr/windows
env:
- name: MTU
value: "1450"
securityContext:
capabilities:
add: ["NET_ADMIN"]
- Windows 容器需镜像支持 PowerShell 网络命令，可用 Set-NetAdapterAdvancedProperty -Name "Ethernet" -DisplayName "MTU" -DisplayValue 1450
验证与收尾
改完不是结束，必须闭环验证：
- 进新调度的 Pod，运行：ip link show eth0 | grep mtu，确认输出为预期值（如 1450）
- 重试原故障操作：HTTPS 请求、大文件 curl、RDP 连接、gRPC 流，观察是否秒级完成
- 检查业务日志是否还有 TLS handshake timeout、connection reset 或 context deadline exceeded
- 对比监控指标：TCP 重传率应从 >1% 降至 0.1% 以下，P99 延迟回归稳定
