标签：学习 linu 版权 namespace 意图 相关 出现 响应 lis
所谓的网络栈包括：网卡、回环设备、路由表、Iptables规则，而对于一个进程来讲，这些要素是构成发起和响应网络请求的基本环境。而对于容器来讲可以直接使用宿主机的网络栈，即不开启Network Namespace,例如：
docker run -d --net=host --name nginx-host nginx
直接监控到宿主机80端口
netstat -ntlp | grep nginx tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 29133/nginx: master
虽然这种方式会提高容器网络性能，但也会不可避免的引入共享网络资源的问题，例如端口冲突等。所以，在大多数情况下，我们都希望容器进程能使用自己的Netword Namespace里的网络栈，拥有自己的IP和端口。
这里我们可以把每一个容器看做一台主机，他们都有自己的一套网络栈。如下想让两个容器互通最简单的办法就是连接一根网线。而想要多台主机相互通信，那就需要一根网线连接到交换机上。在Linux中能起虚拟交换机的作用设备那就是网桥（Bridge），它是工作在数据链路层的设备，主要功能就是根据MAC地址学习来将数据包转发到网桥的不同端口。
而Docker创建的时候会默认在宿主机上创建一个docker 0的网桥，凡是连接在docker 0网桥上的容器，就可以通过他来通信。连接docker 0网桥需要一个Veth Pair的虚拟设备。
Veth Pair特点：它被创建后，总是以两张虚拟网卡的形式成对出现，并且，从其中一个“网卡”发出的数据包可以直接出现在另一张“网卡”上，哪怕这两张网卡在不通的namespace里。这使得Veth Pair常常被称作两个容器间的“网线”。
演示：
启动一个myapp启动，命名为myapp-1
docker run -d --name myapp-1 ikubernetes/myapp:v1
进入到容器，查看一下网络
#进去容器 $ docker exec -it myapp-1 /bin/sh #查看网络 $ ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1046 (1.0 KiB) TX bytes:866 (866.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) $ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 172.17.0.1 0.0.0.0 UG 0 0 0 eth0 172.17.0.0 * 255.255.0.0 U 0 0 0 eth0
可以看到，这个容器有一张eth0的网卡，这个网卡就是Veth Pair设备在容器的这一端，通过route命令查看myapp-1的路由表，可以看到，这个eth0网卡是这个容器的默认路由设备。所有对172.17.0.0/16 网络的请求，也会被交给eth0来处理（第二条规则）
而Veth Pair设备另一端而在宿主机上，我们可以查看宿主机网络设备。如下：
$ ifconfig ..... docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 inet6 fe80::42:a0ff:fed8:f7fb prefixlen 64 scopeid 0x20<link> ether 02:42:a0:d8:f7:fb txqueuelen 0 (Ethernet) RX packets 41 bytes 2581 (2.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 15 bytes 1178 (1.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 vethf34d9da: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::7cf9:b4ff:fefc:fc3c prefixlen 64 scopeid 0x20<link> ether 7e:f9:b4:fc:fc:3c txqueuelen 0 (Ethernet) RX packets 16 bytes 1173 (1.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 19 bytes 1458 (1.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ..... $ brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242a0d8f7fb no vethf34d9da
通过ifconfig命令输出，可以看到，myapp-1容器对应的Veth Pair设备在宿主机上是一张虚拟网卡。名字叫vethf34d9da。并且，通过brctl show的输出，可以看到这张网卡被“插”在docker0上了。
我们再启动一个容器，我们看一下会发生什么
docker run -d --name myapp-2 ikubernetes/myapp:v1
宿主机上查看一下网络设备
brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242a0d8f7fb no veth90a25df vethf34d9da
我们发现vethf34d9da的虚拟网卡“插”在docker0上
我们在myapp-1上ping一下myapp-2的ip，我们会发现是通的。
$ docker exec -it myapp-1 /bin/sh / # ping 172.17.0.3 PING 172.17.0.3 (172.17.0.3): 56 data bytes 64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.296 ms 64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.310 ms
解释一下为什么会通。
当我们myapp-1访问myapp-2的时候，这个目的IP地址会匹配到myapp-1容器里路由规则的第二条，可以看到，这条路由规则的网关是“*”，这就意味是直连规则，即：凡是匹配这个规则的IP包，应该经过eth 0网卡，通过二层网络直接发往目的主机。而要通过二层网络到达nginx-2容器，就需要有172.17.0.3这个IP对应的MAC地址，所以myapp-1容器的网络协议栈，就需要通过eth0网卡发送一个ARP广播，来通过IP地址查找对应的MAC地址。这个eth0网卡是一个Veth Pair，它的一段在myapp-1容器的Network Namespace里，而另一端则位于宿主机上，并“插”在docker0网桥上。
一旦一张虚拟网卡“插”在网桥上，它就变成该网桥的“从设备”，“从设备”会被“剥夺”调用网络协议栈处理数据包的资格，从而降级成为网桥上的一个端口，而这个端口的唯一作用，就是接收流入的数据包，然后这个数据包的“生杀大权”（例如转发、丢弃）全部交给对应的网桥。
所以，在收到这些ARP请求后，docker0网桥就会扮演二层交换机的角色，把ARP广播转发到其他被“插”在docker0上虚拟网卡上。这样，同样连接在docker0上的myapp-2容器的网络协议栈就会收到这个ARP请求，从而将172.17.0.3所对应的MAC地址回复给myapp-1容器。有了这个目的MAC地址，myapp-1容器的eth0网卡就可以将数据包发出去了。而根据Veth Pair设备原理，这个数据包会立即出现在宿主机vethf34d9da虚拟网卡上，不过，此时这个vethf34d9da虚拟网卡的网络协议栈被宿主机docker0剥夺，所以这个数据包将直接流入到docker0网桥里。
对于网桥上流入的数据包，就会通过宿主机的网络协议栈进行处理。需要注意的是，在宿主机上，Docker会为你设置如下路由规则：
route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default bogon 0.0.0.0 UG 100 0 0 ens160 172.16.138.0 0.0.0.0 255.255.255.0 U 100 0 0 ens160 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
而这次流入的数据包的目的地址是172.17.0.3，所以，当他出现宿主机之后，就会按照上述172.17.0.0这条路由规则，在进过docker0网桥（FORWORD）转发出去。
docker0处理转发的过程，则继续扮演二层交换机的角色，此时，docker0根据数据包的目的MAC地址（myapp-2容器的MAC地址），在它的CAM表(既交换机通过MAC地址学习维护的端口和MAC地址对应表)里查到对应的端口为: vethf34d9da，然后将数据转发到这个端口。而这个端口是myapp-2“插”在docker0网桥上的另一张虚拟网卡，当然他也是Veth Pair设备，这样数据包就进入到myapp-2容器里Network Namespace里。这样myapp-2容器的网卡上出现了流入的数据包，就可以对请求进行处理了，处理完成将响应返回给myapp-1。
上述流程示意图
与此类推，当宿主机访问容器的时候，如下示意图：
当一个容器访问另一个宿主机上的容器时，例如：ping 172.16.138.40,它发出的请求数据包，首先经过docker0网桥出现在宿主机上。然后根据宿主机的路由表里直连路由规则（172.16.138.0/24 ens160）对172.16.138.40的访问请求就会交给宿主机的eth0。数据包经过宿主机的eth0 网卡转发宿主机网络上，最终到达172.16.138.40对应的宿主机上，要实现这个首先两台宿主机的网络是连通的，如下图：
所以说当遇到容器连不通“外网”的时候，应该先试试ping docker0的地址通不通，然后在查docker0 和 Veth Pair 设备相关的iptables规则是不是正常。
网络栈
极客时间版权所有: https://time.geekbang.org/column/article/64948网络
网络栈
极客时间版权所有: https://time.geekbang.org/column/article/64948
网络栈
极客时间版权所有: https://time.geekbang.org/column/article/64948
1在大多数情况下，我们都希望容器进程能使用自己 Network...
极客时间版权所有: https://time.geekbang.org/column/article/64948
标签：学习 linu 版权 namespace 意图 相关 出现 响应 lis
原文地址：https://www.cnblogs.com/xzkzzz/p/9929804.html
