docker网络技术剖析

pipework工作原理分析那么容器到底发生了哪些变化呢？我们docker attach到test1上，发现容器中多了一块eth1的网卡，并且配置了192.168.1.150/24的IP，而且默认路由也改为了192.168.1.1。这些都是pipework帮我们配置的。
·首先pipework检查是否存在br0网桥，若不存在，就自己创建。
·创建veth pair设备，用于为容器提供网卡并连接到br0网桥。
·使用docker inspect找到容器在主机中的PID，然后通过PID将容器的网络命名空间链接到/var/run/netns/目录下。这么做的目的是，方便在主机上使用ip netns命令配置容器的网络。因为，在Docker容器中，我们没有权限配置网络环境。
·将之前创建的veth pair设备分别加入容器和网桥中。在容器中的名称默认为eth1，可以通过pipework的-i参数修改该名称。
·然后就是配置新网卡的IP。若在IP地址的后面加上网关地址，那么pipework会重新配置默认路由。这样容器通往外网的流量会经由新配置的eth1出去，而不是通过eth0和docker0。(若想完全抛弃自带的网络设置，在启动容器的时候可以指定--net=none)以上就是pipework配置Docker网络的过程，这和Docker的bridge模式有着相似的步骤。事实上，Docker在实现上也采用了相同的底层机制。通过源代码，可以看出，pipework通过封装Linux上的ip、brctl等命令，简化了在复杂场景下对容器连接的操作命令，为我们配置复杂的网络拓扑提供了一个强有力的工具。当然，如果想了解底层的操作，我们也可以直接使用这些Linux命令来完成工作，甚至可以根据自己的需求，添加额外的功能。
2 单主机Docker容器VLAN划分pipework不仅可以使用Linux bridge连接Docker容器，还可以与OpenVswitch结合，实现Docker容器的VLAN划分。下面，就来简单演示一下，在单机环境下，如何实现Docker容器间的二层隔离。为了演示隔离效果，我们将4个容器放在了同一个IP网段中。但实际他们是二层隔离的两个网络，有不同的广播域。
安装openvswitch
安装基础环境
yum install –y gcc make python-developenssl-devel kernel-devel graphviz \
kernel-debug-devel autoconf automake rpm-build redhat-rpm-config \
libtool

解压与打包
tar zxvf openvswitch-2.3.1.tar.gz
mkdir -p ~/rpmbuild/SOURCES
cp openvswitch-2.3.1.tar.gz  ~/rpmbuild/SOURCES/
sed 's/openvswitch-kmod, //g'openvswitch-2.3.1/rhel/openvswitch.spec >openvswitch-2.3.1/rhel/openvswitch_no_kmod.spec
rpmbuild -bb --without checkopenvswitch-2.3.1/rhel/openvswitch_no_kmod.spec

之后会在~/rpmbuild/RPMS/x86_64/里有2个文件

安装第一个就行

启动
Systemctl start openvswitch
查看状态

或

可以看到是正常运行状态
安装pipework   过程略，参考前面的操作
创建交换机，把物理网卡加入ovs1


在主机A上创建4个Docker容器，test1、test2、test3、test4

将test1，test2划分到一个vlan中，vlan在mac地址后加@指定，此处mac地址省略

完成上述操作后，使用docker attach连到容器中，然后用ping命令测试连通性，发现test1和test2可以相互通信，但与test3和test4隔离。这样，一个简单的VLAN隔离容器网络就已经完成。由于OpenVswitch本身支持VLAN功能，所以这里pipework所做的工作和之前介绍的基本一样，只不过将Linux bridge替换成了OpenVswitch，在将veth pair的一端加入ovs0网桥时，指定了tag。底层操作如下：ovs-vsctl add-port ovs0 veth* tag=100