容器化Bridge模式的网络异常表象

背景

客户访问系统的auth登录页面，发现提示服务不可用，在F12中的反馈为Connection refused。

排查过程

1、检查java登录服务的日志，发现20880/8999端口Connection refused，怀疑为网络层面问题。

2、ss -ntlp | grep 20880查看宿主机中的容器服务映射，发现由docker-proxy进程正常启动了。

3、telnet 127.0.0.1 20880测试连接性。

[root@awsome awsome-path]# telnet 127.0.0.1 20880
Trying 127.0.0.1...
Connected to 127.0.0.1
Escape character is '^]'.
Connection closed by foreign host.

发现在显示Connected to 127.0.0.1后立刻Connection closed by foreign host；这是一个疑点，连接了一瞬间后立即被拒绝了。

iptables -I INPUT -j ACCEPT

尽管直接允许所有流量，但是还是被拒绝。

4、将java容器改为host模式，发现dubbo绑定的IP为docker创建的bridge，目前该IP已无任何容器使用。

• 既然无任何容器使用该bridge了，直接手动ip link delete删除掉再重启看看。
• 添加一个参数--cloud.dubbo-server.all-provider-url=[tri://127.0.0.1:20880]()

并没有解决connection refused！

5、docker stats –no-stream查看auth登录服务的资源占用情况，发现其只使用了所分配空间的一半。

目前网络流量放通、dubbo使用环回，依旧无法成功访问。

根因

1. bridge模式下分配的Auth容器内，服务的内存空间不够进程使用，因此持续重启，在多次失败后进程取消了重试，同时释放了足量内存空间，出现了docker stats似乎资源可用的情况；
2. 运行失败后，容器内进程取消了20880的listen，而由于是bridge模式，宿主机中的网络命名空间保持着20880 listen的监听；但是20880在Auth容器的网络命名空间中不可达，所以出现telnet连通（宿主机）但立即Connection closed（容器内）的现象。