场景描述：
openstack私有云中的容器服务A(部署在openshift上)需要通过http访问阿里云中的B服务，中间需要经过openstack的nat网关，以及阿里云的lb。但在访问时发现访问失败，A服务无法获取B服务的http响应。
问题分析：
容器中的服务A请求阿里云的服务B时失败，但在容器所在的node节点直接curl该url是成功的，说明底层网络连接是通的。在A服务和B服务所在的node节点抓包发现，A服务发送http请求时，tcp链路是通的，但由于没有接收到B服务的http response，A服务判断业务超时，发送tcp断链
但在B服务端可以看到，它其实已经正确回复了A服务的http request。因此猜测报文可能被A服务的node或网关丢弃了。
为排除问题，将A服务部署在非openstack环境中，环境部署如下，发现A服务可以正常访问B服务，可以排除阿里云的问题。
回到出问题的环境，出现网络丢包的原因一般出现在如下场景：
- 防火墙，包括一些权限策略类的设置，如selinux，apparmor，iptables等
- 网络传输或接收设备繁忙，可能如cpu过载，内存不足，缓存队列满等
- 网络参数配置，如tcp超时参数设置，最大连接数，接口mtu等
本环境中网络负载很小，且数据是可以在两端传输的，可以排除1，2两点。由于使用curl可以正常访问服务B，可以判断A服务所在的node节点上的某些配置可能会导致丢包。仔细观察A服务主动发出的报文和使用curl发出的报文，可以发现两者在MSS上有所不同，A服务发出的MSS为1460，而使用curl则是1260
使用如下目录将A服务所在的node节点从eth0发送的TCP的MSS设置为1260，此时发现A服务可以正常访问B服务
代码语言：javascript复制iptables -t nat -I POSTROUTING -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t nat -I POSTROUTING -o eth0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1260由此得出，该问题是因为A服务发出的MTU不正确导致的。使用ip link命令查看A服务所在节点的eth0的MTU，值为1300。而A服务所在容器的eth0为1500，这样就导致了A服务发出的tcp报文的MSS大于它所在节点的MSS，B服务(MSS为1460)发送的报文大于A服务所在集群可接收大小之后会被网关或node节点丢弃
修复方法：
在docker daemon中添加如下参数，重启docker(必要时重启node)即可将容器的mss修改为1260
代码语言：javascript复制# cat /etc/docker/daemon.json
{
"mtu": 1300
}PS：
- openshift容器会自适应host的mtu，参见Optimizing the MTU for Your Network。一般情况下，SDN会占用50字节，因此openshift中的MTU=HostMtu-50
