网络概述
1，Linux的namespace+cgroup
namespace和cgroup是Linux 内核的两大特性，namespace的诞生据说就是为了支持容器技术，那么这俩特性到底干了啥呢？
- namespace：linux支持多种类型的namespace，包括Network，IPC，PID, Mount, UTC, User。创建不同类型的namespace就相当于从不同资源维度在主机上作隔离。
- cgroup：为了不让某个进程一家独大，而其他进程饿死，所以它的作用就是控制各进程分配的CPU，Memory，IO等。
- namespace+cgroup也适用进程组，即多进程运行在一个单独的ns中，此时该ns下的进程就可以交互了。
参考：https://coolshell.cn/articles/17010.html
2，容器
"容器"这个概念其实是Linux本身就具有的，无非就是对一个"隔离环境"的另一种说法，或者说容器就是结合了namespace 和 cgroup 的一般内核进程，注意，容器就是个进程。
容器的实现有多种方式，其中Docker公司实现的docker 容器也是目前最为常用的一种容器技术，所以我们接下来就以docker为例，看看他的实现是怎么帮我们创建，管理这样一个个"互相隔离着的进程"。
所以，当我们使用Docker起一个容器的时候，Docker会为每一个容器创建属于他自己的namespaces，即各个维度资源都专属这个容器了，此时的容器就是一个孤岛，也可以说是一个独立VM就诞生了。当然他不是VM，网上关于二者的区别和优劣有一对资料.
更进一步，也可以将多个容器共享一个namespace，比如如果容器共享的是network 类型的namespace，那么这些容器就可以通过 localhost：[端口号] 来通信了。因为此时的两个容器从网络的角度看，和宿主机上的两个内核进程没啥区别。
在下面的详解部分会有试验来验证这个理论
Docker容器网络详解
从范围上分：
单机网络：none，host， bridge
跨主机网络：overlay，macvlan，flannel等
从生成方式分：
原生网络：即利用宿主机操作系统本身就提供的功能构建的网络，包括：none，host， bridge
自定义网络：
docker容器实现中自带的网络驱动：bridge(自定义)，overlay，macvlan，
使用第三方驱动实现的自定义网络：flannel等
在学习网络的时候肯定遇到过关于CNM这个概念，所以首先，我们一起学习下CNM&libnetwork
一. CNM&libnetwork
首先，Docker实现的容器技术中，针对网络这一块他抽象出一个模型来，就叫CNM(Container Networking Model)，相当于只实现了一个框架，具体的实现可以使用原生Docker的，也可以自己实现然后接入本框架。其中libnetwork是Docker团队将Docker的网络功能从Docker的核心代码中分离出来形成的一个单独的库，libnetwork通过插件的形式接入CNM为Docker提供网络功能。
该模型包含三部分：
- Sandbox：容器的网络栈，包含interface，路由表，DNS设置等，可以看做就是linux network类型的namespace本身，该有的网络方面的东西都要有，另外还包含一些用于连接各种网络的endpoint
- Endpoint ： 用来将sandbox接入到network中。典型的实现是Veth pair技术（Veth pair是Linux固有的，是一个成对的接口,用来做连接用）
- Network (框架)： 具体的网络实现，比如是brige，VLAN等，同样它包含了很多endpoint(那一头)
一句话：sandbox代表容器，network代表由网络驱动构建的容器的网络，endpoint代表接入点即他连接了二者
CMN模型提供了2个可插拔的接口，让用户可以自己实现驱动然后接入该接口，支持驱动有两类：网络驱动和IPAM驱动，看看这俩类驱动干什么的？
-
Network Drivers： 即真正的网络实现，可以为Docker Engine或其他类型的集群网络同时提供多种驱动，但是每一个具体的网络只能实例化一个网络驱动。细分为本地网络驱动和远端网络驱动：
- 本地网络驱动：对应前面说到的原生网络
- 远端网络驱动：对应前面说的自定义网络
- IPAM Drivers — 构建docker网络的时候，每个docker容器如果不手动指定的话是会被分配ip地址的，这个分配的任务就是由该驱动完成的，同样的，Docker Engine还是给我们提供了缺省的实现。
整个的原理模型图如下，参见官网：
参考：https://success.docker.com/article/networking
（一定要好好看看这篇文章，我英文不行看了整整2天，很有收获）
好了，收，开始真正进入docker网络的学习，我们挑2个代表性的网络一起研究下
二. 单机网络---brige类型的网络
原理如下图（摘自https://success.docker.com/article/networking）：
接下来听我慢慢道来，我们先按照步骤走一遍，然后再细抠里面的原理
1. 从实践开始
在主机上起两个docker容器，使用缺省网络即bridge网络，容器要使用有操作系统的镜像，要不不方便验证
1)进入任一个容器内
sh-4.2# ip addr
13: eth0@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
inet 172.17.0.3/16 scope global eth0
附：容器中可能缺少诸多命令，可以在启动后安装如下工具：
yum install net-tools
yum install iputils
yum install iproute *
2)在宿主机上查看接口信息:
[root@centos network-scripts]# ip addr
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
inet 172.17.0.1/16 scope global docker0
14: vetha470484@if13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
16: veth25dfcae@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
3) 在host上查看docker缺省会创建的三个网络
[root@centos ~]# docker network ls
NETWORK ID NAME DRIVER SCOPE
451a2ff68c71 bridge bridge local
7bd661f0c17f host host local
6c9bb2d42d95 none null local
4)再看下支撑网络背后的驱动,即这个叫“bridge”的bridge类型网络使用的驱动：一个名叫docker0的bridge(网桥)。网桥上挂两个interface：veth25dfcae， vetha470484
[root@centos network-scripts]# brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242dee689ea no veth25dfcae #宿主机上16号接口，@if15，即和容器中15号端口是一对veth pair vetha470484 #宿主机上14号接口，@if13，即和容器中13号端口是一对veth pair
附:可能缺少命令，可以在启动后安装如下工具：
# yum install bridge-utils
#ln -s /var/run/docker/netns/ /var/run/netns ---用来在host上查看所有的namespace,缺省情况下ip show显示的是/var/run/netns中的内容，但是Docker启动后会清除
容器中也可能缺少命令，使用如下方式将宿主机上的命令拷贝到容器中
[root@node231 ~]# docker cp /usr/bin/netstat c121e2854008:/usr/bin/ [root@node231 ~]# docker cp /usr/sbin/ifconfig c121e2854008:/usr/sbin/ [root@node231 ~]# docker cp /usr/sbin/ip c121e2854008:/usr/sbin/
2. 解析Docker都做了什么
看容器(Sandbox)， 接口的number是13的那个，他名字是eth0， 然后他@if14，这个就是endpoint，那么这个if14是谁？
看主机，有个网桥叫做docker0，有两个interface 他们的master是docker0，并且这两个interface的number分别是14，16，并且分别@if13和@if15，是的，if13正是容器中的接口，同理if14也是另一个容器中的接口，也就是说在host上的veth接口（NO.14）和容器中的eth接口(NO.13)正是一对veth pair,至此Endpoint作为容器和nework的连接的任务达成了。而docker0正是名叫bridge的Network的驱动。
最后，看一下路由吧
容器1：
sh-4.2# ip route default via 172.17.0.1 dev eth0 172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.3
# 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
表示：目的是172.17的是一条直连路由，直接从eth0出去交给网关172.17.0.1(也就是docker0)
宿主机：
[root@centos ~]# ip route default via 192.168.12.2 dev ens33 proto dhcp metric 100 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 192.168.12.0/24 dev ens33 proto kernel scope link src 192.168.12.132 metric 100
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
表示：目的是172.17的流量从docker0出去，
缺省的交给ens33接口给网关192.168.12.2(因为我的宿主机是个虚拟机，所以还是个小网ip),也就是说如果访问的是同网段(如加入同一网络的其他容器)则交给网桥docker0内部转发，否则走向世界
另外：详细的可以 看一下bridge网络,可以网络中有两个容器，ip，mac都有
[root@centos ~]# docker network inspect bridge
{
"Name": "bridge",
"Driver": "bridge",
"IPAM": { //负责给容器分配ip地址
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
},
"Containers": {
"9161f717c07ac32f96b1ede19d21a56a63f17fb69a63627f66704f5cec01ca27": {
"Name": "server.1.oeep0sn0121wrvrw3aunmf9ww",
"EndpointID": "5083992493b0a69fedb2adc02fe9c0aa61e59b068e16dd9371ec27e28d7d088c",
"MacAddress": "02:42:ac:11:00:02",
"IPv4Address": "172.17.0.2/16",""
},
"fb67b65aa43619779d0d4f9d2005815aea90586f0aba295436431f688239562b": {
"Name": "fervent_ritchie",
"EndpointID": "e402fa0f99f60199c8ba50263173ef3bc14ca75dbb597d2cbcd813dd4f8706f7",
"MacAddress": "02:42:ac:11:00:03",
"IPv4Address": "172.17.0.3/16",
}
},