手把手教你实现Docker部署Redis集群 Docker的技术依赖于Linux内核的虚拟化

Docker的技术依赖于Linux内核的虚拟化技术的发展， Docker使用到的网络技术有Network Namespace、Veth设备对、Iptables/Netfilter、网桥、路由等。接下来，我将以Docker容器网络实现的基础技术来分别阐述，在到真正的容器篇章节之前，能形成一个稳固的基础知识网。
Network Namespace为了支持网络协议栈的多个实例， Linux在网络栈引入了Network Namespace ，这些独立的协议栈被隔离到不同的Namespace中，处于不同Namespace中的网络栈是完全隔离的，彼此无法通信。具体有关Linux Namespace的介绍，可以另行浏览之前写的《Linux Namespace》。
Linux的网络协议栈十分复杂，为了支持独立的协议栈，相关的全局变量都必须修改为协议栈私有。 Linux实现Network Namespace的核心就是让这些全局变量称为Network Namespace变量的成员，然后为协议栈的函数调用加入一个Namespace参数。与此同时，为了保证已开发程序及内核代码的兼容性，内核代码隐式地使用了Namespace空间内的变量。应用程序如果没有对Namespace有特殊需求，那么不需要额外的代码， Network Namespace对应用程序而言是透明的。
【手把手教你实现Docker部署Redis集群】在建立了新的Network Namespace ，并将某个进程关联到这个网络命名空间后，就出现了如下的命名空间下的内核数据结构，所有网络栈变量都放入了Network Namespace的数据结构中，这个Network Namespace是属于它进程组私有的，与其他进程组不冲突。
文章插图
Docker正是利用了Network Namespace特性，实现了不同容器之间的网络隔离。如果一个容器声明使用宿主机的网络栈（-net = host），即不开启Network Namespace ，例如：
docker run –d –net=host --name c_name i_name这种情况下，这个容器启动之后监听的是宿主机的80端口。像这样直接使用宿主机网络栈的方式，虽然可以为容器提供良好的网络性能，但也不可避免的造成端口冲突等网络资源冲突的问题。
所以在一般情况下，我们都希望程序引入Network Namespace里的网络栈，即这个容器拥有自己的IP和端口。但是，这个时候也会带来一个新的问题，被隔离的容器进程，是怎么与其它被隔离的进程进行网络通信的？
Net Bridge上文说到， Linux 可以支持不同的网络，他们之间是怎么支持够互相通信的呢？如果是两台主机，那需要的可能只是一根网线，把它们连接在一台交换机上。而在Linux当中，网桥（Bridge）就起到相应的作用。本质上来说，这是一个数据链路层（data link）的设备，根据Mac地址的信息转发到网桥的不同端口上。而Docker就是在宿主机上默认创建一个docker0的网桥，凡是连接docker0的网桥，都可以用它来通信。
细述Bridge网桥是一个二层的虚拟网络设备，把若干个网络接口“连接”起来，使得网口之间的报文可以转发。网桥能够解析收发的报文，读取目标的Mac地址信息，和自己的Mac地址表结合，来决策报文转发的目标网口。为了实现这些功能，网桥会学习源Mac地址。在转发报文时，网桥只需要向特定的端口转发，从而避免不必要的网络交互。如果它遇到了一个自己从未学过的地址，就无法知道这个报文应该向哪个网口转发，就将报文广播给除了报文来源之外的所有网口。
在实际网络中，网络拓扑不可能永久不变。如果设备移动到另一个端口上，而它没有发送任何数据，那么网桥设备就无法感知到这个变化，结果网桥还是向原来的端口发数据包，在这种情况下数据就会丢失。所以网桥还要对学习到的Mac地址表加上超时时间，默认5min 。如果网桥收到了对应端口MAC地址回发的包。则重置超时时间，否则过了超时时间后，就认为哪个设备不在那个端口上了，他就会广播重发。