一般来讲，我们安装完docker，就会查看到docker的网络，如下
[root@master1 ~]# docker network ls
NETWORK ID NAME DRIVER SCOPE
f199b6319d94 bridge bridge local
3b93f4bad0a9 host host local
6b6f0e006e46 none null local
[root@master1 ~]#下面我们就介绍一下docker这些原生的网络是什么意思？
1. none网路
啥都没有，IPAM（IP address manager网络管理）也是空的。
运行一个容器，没有ip地址，也ping不通百度，没有对外通讯的网卡，也没有DNS。能够ping通172.0.0.1，说明能做一个本地环回的封装，它存在的意义在于安全性高，因为与外界隔离了。
2. host网络
我们运行一个容器看看，跟宿主机的网路是一模一样的 ，连hostname也是一样的。
好处是性能非常的好，如果容器对网络的性能要求极其的高，那么就可以使用这个网络模式。
缺点就是牺牲一些灵活性，比如说端口冲突。
3. join网络
这个网络是我们看不到的，使用docker network ls
实际的应用场景就是，比如说我们运行一个Apache的容器，想要看容器的ip地址，但是httpd这个镜像里面没有ip，ifconfig，yum命令。
这个时候可以通过我们的join网络，具体操作如下：
即让我们两个容器使用相同的网络配置。。
我们使用docker inspect web这个命令也可以看到该容器的IP地址，所以这个网络的话，基本用不到，只做了解即可。
4. bridge网络
我们使用brctl命令可以看到宿主机的桥接卡信息
[root@master1 ~]# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02427edf5f3a no vethffb877b
[root@master1 ~]# 网络必须满足三个条件才能通讯：一个网段=一个广播域=一个VLAN（所有的主机要在一个网段，一个广播域，一个VLAN中），但是这个也不是绝对的，例如：flannel网络可以实现所有网段都可以通信。
默认情况下，我们启动一个容器，该容器的网卡都会连到docker0这个网桥去。
我们知道docker0的网桥ip地址是172.17.0.1，这里我们看看我们起的httpd容器的IP地址。
看到容器里面的网卡eth0连接到7号这个网卡，我们看一下宿主机上7号网卡veth2e29983，刚好也是显示连接到6号这个网卡（容器内部的那个网卡）
使用brctl show命令，veth2e29983连接到docker0上
[root@master1 ~]# brctl show
bridge name bridge id STP enabled interfaces
docker0 8000.02427edf5f3a no veth2e29983
[root@master1 ~]# 查看一下bridge网卡信息
网段是172.17.0.0/16
网关是172.17.0.1
发现docker0充当的是这个bridge网桥的网关地址。。。
?veth pair连接的是不同空间的，同一个空间相连的就用桥接关系，我们这里的空间指的是网络空间，即 ip netns，关于ip netns的说明，可以参考我的另一篇docker namespaces详解
那么我们的docker0又是如何与宿主机网卡相连的呢，即我们的容器如何访问外的呢？
依靠的是路由表（ip_forward），路由表的作用是把数据跨网段进行转发，sysctl -p是查看是否开启路由转发功能，若未开启，可根据下面的方式修改即可。
??打开之后，我们可以根据ip r（或route -n）看到的路由表能进行数据转发了。
上面的是默认的情况下，下面我们介绍一下通过自定义的网络
[root@master1 ~]# docker network create --driver bridge my_net
c15eb9e22ac268a22537ead5de4046f505351d5d41fe22053710da0e73d6d532
[root@master1 ~]# docker network ls
NETWORK ID NAME DRIVER SCOPE
f199b6319d94 bridge bridge local
3b93f4bad0a9 host host local
c15eb9e22ac2 my_net bridge local
6b6f0e006e46 none null local
[root@master1 ~]#我们创建的docker网络，是172.18.x.x，这个是docker默认给我们分配的，注意要是我们再create一个，就是172.19.x.x，这个规律还是显而易见的。
现在如果我想自己定义网段那些的话，通过如下命令即可：
查看一下网桥，br-4da9e772021c这个网卡就是我们刚才自定义出来的网卡。
我们发现我们创建的那个docker桥接网卡（my_net2）的Gateway网关(172.22.16.1)就是在物理机创建的网卡的ip地址(br-4da9e772021c的ip)。
现在我们做个试验，让我们刚才新创建的网卡去ping docker默认docker0管理创建的容器ip，即不同的桥接卡下的veth pair容器看看能否通讯。答案是肯定不能通讯的，因为都不在同一个网段上，如下我们演示的两个不同的容器bbox1和bbox2，它两不能通讯，但是能够ping通网关ip。
但是我们额外测试一个注意的情况
由于我们知道172.17.0.1是docker0的IP地址，这里我们通过my_net这个bridge卡创建一个bbox1的容器，然后172.17.0.2是我们刚开始后台起的httpd服务的容器地址，发现172.17.0.1（这个也是bbox1容器的网关ip）可以通，172.17.0.2不可以通，也就是说我们可以ping通这是怎么回事呢？
我们ping不通172.17.0.2是符合常理的，因为不在同一个网段中，但是它的网关通了
，原因是防火墙的规则在作用着，使用iptables-save命令查看一下物理机的防火墙
docker0到br-4da9e772021c，br-c15eb9e22ac2网桥的流量都被DROP掉了，防火墙挡住了。
如果想要连接到httpd这个服务容器（也就是web这个容器）的话，解决办法就是让httpd容器多一个网卡。
[root@master1 ~]# docker network connect my_net web //把my_net这个docker network连接到web这个容器
发现这个web容器，除了自己run的时候通过docker0的那块网卡，现在多了一个网卡，如下所示
?此时再去ping httpd服务的容器（即web这个容器）
总结：
- none：啥都没有
- host：与主机相同
- joined：两个容器相同
- bridge：通过docker虚拟出的桥接卡进行通讯
- Bridge模式，docker容器会拥有一个自己独立的Network Namespace，然后会建立一个veth对，一端连接着容器，另外一端连接docekr0网桥
- Host 模式，docker容器不会拥有自己独立的Network Namespace，而是和宿主机共享同一个Network Namespace，使用同样的环境
- Container（join）模式，docker容器会跟应存在的容器共享同一个Network Namespace
- None 模式，docker容器会拥有独立的Network Namespace，但是不会进行任何的网络设置，只有一个网络回环地址
我的第一个微单
