一、概述
二、bridge网络模式
介绍
关于veth
容器与容器间通讯
启动一个bs1的容器，并查看其IP地址为172.17.0.2，默认网关为172.17.0.1。而这个网关地址则是网桥docker0地址：
同时我们查看docker0桥接的网卡与刚才容器对应的veth网卡：
同样的在启动一个容器为bs2,IP地址为172.17.0.3 ，网关172.17.0.1，即也是docker0：
此时docker0上会多了一个bs2的veth设备veth7833d44：
当我们从容器bs1中ping 172.17.0.3（容器bs2）时候，在bs1容器里，根据路由规则，数据包从eth0转发址与之对应的veth（veth0737c95）上，该veth桥接在了docker0上，此时数据包到达了docker0，docker0此时扮演交换机角色并广播ARP请求寻找172.17.0.3的mac地址，而此时的bs2的另一个veth设备桥接在了docker0上并收到该ARP请求，发现自己是172.17.0.3，将其mac地址回复给bs1，此时的容器bs1就可以和bs2进行通讯了，并且在bs1上可以查看到缓存的172.17.0.3的mac地址：
以上的两个容器间的通讯过程示意图如下：
容器与外部网络通讯
同样的，介绍了容器与容器间的通讯，容器与主机间的通讯就容易理解了，如果在容器bs1 ping 另一个主机10.168.0.3，它发出去的数据包经过docker0网桥流向eth0，eth0在将数据包转发给与之相通的10.168.0.3，于是bs1就能和其主机节点进行通讯了。当然如果这个地址不是其他主机节点而是公网地址，只要eth0能到达，容器bs1都能与之通讯。以下是其示意图：
宿主机与容器通讯
当宿主机访问容器时，数据包从docker0流入到与容器对应的veth设备，在经容器的eth0到达到主机中，示意图如下：
外部访问容器
默认情况，其他外部网络（宿主机以外）无法访问到容器内的端口，通常的做法是使用-p或者-P选项（使用方法参考docker基础篇）来暴露容器中的端口到宿主机上，外部网络通过访问宿主机的端口从而访问到容器端口。本质上来说，该方式是通过iptables规则转发实现的，例如以下启动nginx容器并使用宿主机的8080映射到容器内部80端口：
查看其对应的iptables规则：
上述规则表明当访问宿主机的8080端口时，NAT到容器中的172.17.0.4的80中。
自定义网桥
除了使用默认docker0作网桥以为还可以使用docker network 相关命令自定义网桥，以下将创建一个br1的网络，子网是172.30.0.0/16，网关为172.30.0.1:
查看docker网络：
查看对应网桥：
此时运行一个容器指明网络使用br1,此时的容器地址使用的是172.30.0.0段的网络,此时使用的网桥为br-9e5b3fba2e11，如下：
三、host网络模式
Host模式使用是在容器启动时候指明--network host，此时容器共享宿主机的Network Namespace，容器内启动的端口直接是宿主机的端口，并且容器不会创建网卡和IP，直接使用宿主机的网卡和IP，但是容器内的其他资源是隔离的，如文件系统、用户和用户组。这种模式的好处就是效率高，因为不需要额外的网络开始，直接使用宿主机网络。同样启动一个nginx，此时共享主机网络：
此时连入容器内部直接能看到docker0与宿主机网卡：
以上的host网络模式下的示意图：
四、container网络模式
理解了host模式就很容易理解container模式，host模式是容器共享宿主机的Network Namespace，而container模式即共享已存在的容器的Network Namespace，此时这两容器共同使用同一网卡、主机名、IP地址，容器间通讯可直接通过lo回环接口通讯，但是其他名称空间是隔离的，例如User、Mount。如果你了解kubernetes中的pod的话，pod内的网络也是靠这样的共享方式来实现的。
这里启动一个bs-1容器，IP地址为172.17.0.2：
此时再运行一个容器共享bs-1的网络,此时在bs-2的容器同样看到的是bs1的网卡：
示意图：
五、none网络模式
使用--network none选项指定其网络模式，在该模式下虽然容器有着自己的Network Namespace，但是容器内没有网卡、IP、路由信息，只有一个lo回环接口。如果需要网络配置则需要用户手动进行配置网卡、ip以及路由信息，通常这样的容器用于承担某些无需网络介入的工作，如离线任务、备份等。启动一个none网络模式的容器如下：
示意图：
