前文说到容器网络对Linux虚拟化技术的依赖，这一篇章咱们将一探到底，看看Docker到底是怎么做的。
通常，Linux容器的网络是被隔离在它本人的Network Namespace中，其中就包含：网卡（Network Interface）、回环设施（Loopback Device）、路由表（Routing Table）和iptables规定。
对于一个过程来说，这些因素，就形成了它发动和响应网络申请的根本环境。
管中窥豹
咱们在执行docker run -d --name xxx之后，进入容器外部：
## docker ps 可查看所有docker## 进入容器docker exec -it 228ae947b20e /bin/bash并执行 ifconfig：
$ ifconfigeth0 Link encap:Ethernet HWaddr 22:A4:C8:79:DD:1A inet addr:192.168.65.28 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1440 Metric:1 RX packets:2231528 errors:0 dropped:0 overruns:0 frame:0 TX packets:3340914 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:249385222 (237.8 MiB) TX bytes:590701793 (563.3 MiB)lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 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)咱们看到一张叫eth0的网卡，它正是一个Veth Pair设施在容器的这一端。咱们再通过 route 查看该容器的路由表：
$ routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 169.254.1.1 0.0.0.0 UG 0 0 0 eth0169.254.1.1 * 255.255.255.255 UH 0 0 0 eth0咱们能够看到这个eth0是这个容器的默认路由设施。咱们也能够通过第二条路由规定，看到所有对 169.254.1.1/16 网段的申请都会交由eth0来解决。而Veth Pair 设施的另一端，则在宿主机上，咱们同样也能够通过查看宿主机的网络设备来查看它：
$ ifconfig......eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.241.192 netmask 255.255.240.0 broadcast 172.16.255.255 ether 00:16:3e:0a:f3:75 txqueuelen 1000 (Ethernet) RX packets 3168620550 bytes 727592674740 (677.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2937180637 bytes 8661914052727 (7.8 TiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0......docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:16:58:92:43 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0......vethd08be47: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 16:37:8d:fe:36:eb txqueuelen 0 (Ethernet) RX packets 193 bytes 22658 (22.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 134 bytes 23655 (23.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0......在宿主机上，容器对应的Veth Pair设施是一张虚构网卡，咱们再用brctl show命令查看网桥：
$ brctl showbridge name bridge id STP enabled interfacesdocker0 8000.0242afb1a841 no vethd08be47能够分明的看到Veth Pair的一端 vethd08be47 就插在 docker0 上。我当初执行docker run 启动两个容器，就会发现docker0上插入两个容器的 Veth Pair的一端。如果咱们在一个容器外部相互ping另外一个容器的IP地址，是不是也能ping通？
$ brctl showbridge name bridge id STP enabled interfacesdocker0 8000.0242afb1a841 no veth26cf2cc veth8762ad2容器1：
$ docker exec -it f8014a4d34d0 /bin/bash$ ifconfigeth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:03 inet addr:172.17.0.3 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:76 errors:0 dropped:0 overruns:0 frame:0 TX packets:106 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:16481 (16.0 KiB) TX bytes:14711 (14.3 KiB)lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:48 errors:0 dropped:0 overruns:0 frame:0 TX packets:48 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2400 (2.3 KiB) TX bytes:2400 (2.3 KiB)$ routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 172.17.0.1 0.0.0.0 UG 0 0 0 eth0172.17.0.0 * 255.255.0.0 U 0 0 0 eth0容器2：
$ docker exec -it 9a6f38076c04 /bin/bash$ ifconfigeth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:133 errors:0 dropped:0 overruns:0 frame:0 TX packets:193 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:23423 (22.8 KiB) TX bytes:22624 (22.0 KiB)lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:198 errors:0 dropped:0 overruns:0 frame:0 TX packets:198 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9900 (9.6 KiB) TX bytes:9900 (9.6 KiB)$ routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Ifacedefault 172.17.0.1 0.0.0.0 UG 0 0 0 eth0172.17.0.0 * 255.255.0.0 U 0 0 0 eth0从一个容器ping另外一个容器：
# -> 容器1外部 ping 容器2$ ping 172.17.0.3PING 172.17.0.3 (172.17.0.3): 56 data bytes64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.142 ms64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.096 ms64 bytes from 172.17.0.3: seq=2 ttl=64 time=0.089 ms咱们看到，在一个容器外部ping另外一个容器的ip，是能够ping通的。也就意味着，这两个容器是能够相互通信的。
容器通信
咱们无妨联合前文时所说的，了解下为什么一个容器能拜访另一个容器？先简略看如一幅图：
当在容器1里拜访容器2的地址，这个时候目标IP地址会匹配到容器1的第二条路由规定，这条路由规定的Gateway是0.0.0.0，意味着这是一条直连规定，也就是说但凡匹配到这个路由规定的申请，会间接通过eth0网卡，通过二层网络发往目标主机。而要通过二层网络达到容器2，就须要127.17.0.3对应的MAC地址。
所以，容器1的网络协议栈就须要通过eth0网卡来发送一个ARP播送，通过IP找到MAC地址。所谓ARP（Address Resolution Protocol），就是通过三层IP地址找到二层的MAC地址的协定。这里说到的eth0，就是Veth Pair的一端，另一端则插在了宿主机的docker0网桥上。eth0这样的虚构网卡插在docker0上，也就意味着eth0变成docker0网桥的“从设施”。从设施会降级成docker0设施的端口，而调用网络协议栈解决数据包的资格全副交给docker0网桥。
所以，在收到ARP申请之后，docker0就会表演二层交换机的角色，把ARP播送发给其它插在docker0网桥的虚构网卡上，这样，127.17.0.3就会收到这个播送，并把其MAC地址返回给容器1。有了这个MAC地址，容器1的eth0的网卡就能够把数据包发送进来。这个数据包会通过Veth Pair在宿主机的另一端veth26cf2cc，间接交给docker0。
docker0转发的过程，就是持续表演二层交换机，docker0依据数据包的指标MAC地址，在CAM表查到对应的端口为veth8762ad2，而后把数据包发往这个端口。而这个端口，就是容器2的Veth Pair在宿主机的另一端，这样，数据包就进入了容器2的Network Namespace，最终容器2将响应（Ping）返回给容器1。在实在的数据传递中，Linux内核Netfilter/Iptables也会参加其中，这里不再赘述。
CAM就是交换机通过MAC地址学习保护端口和MAC地址的对应表。
这里介绍的容器间的通信形式就是docker中最常见的bridge模式，当然此外还有host模式、container模式、none模式等，对其它模式有趣味的能够去浏览相干材料。
跨主通信
好了，这里不禁问个问题，到目前为止只是单主机外部的容器间通信，那跨主机网络呢？在Docker默认配置下，一台宿主机的docker0网桥是无奈和其它宿主机连通的，它们之间没有任何关联，所以这些网桥上的容器，天然就没方法多主机之间相互通信。然而无论怎么变动，情理都是一样的，如果咱们创立一个公共的网桥，是不是集群中所有容器都能够通过这个公共网桥去连贯？
当然在失常的状况下，节点与节点的通信往往能够通过NAT的形式，然而，这个在互联网倒退的明天，在容器化环境下未必实用。例如在向注册核心注册实例的时候，必定会携带IP，在失常物理机内的利用当然没有问题，然而容器化环境却未必，容器内的IP很可能就是上文所说的172.17.0.2，多个节点都会存在这个IP，大概率这个IP是抵触的。
如果咱们想防止这个问题，就会携带宿主机的IP和映射的端口去注册。然而这又带来一个问题，即容器内的利用去意识到这是一个容器，而非物理机，当在容器内，利用须要去拿容器所在的物理机的IP，当在容器外，利用须要去拿以后物理机的IP。显然，这并不是一个很好的设计，这须要利用去配合配置。所以，基于此，咱们必定要寻找其余的容器网络解决方案。
在上图这种容器网络中，咱们须要在咱们已有的主机网络上，通过软件构建一个笼罩在多个主机之上，且能把所有容器连通的虚构网络。这种就是Overlay Network（笼罩网络）。对于这些具体的网络解决方案，例如Flannel、Calico等，我会在后续篇幅持续陈说。
福利：豆花同学为大家精心整顿了一份对于linux和python的学习材料大合集！有须要的小伙伴们，关注豆花集体公众号：python头条！回复关键词“材料合集”即可收费支付！