Docker 网络之进阶篇
笔者在《Docker 基础 : 网络配置》一文中简单介绍了容器网络的基本用法，当时网络的基本使用方式还处于 --link 阶段。时过境迁，随着 docker 的快速发展，其网络架构也在不断的演进。本文主要介绍 docker 的 CNM 网络模型以及新引入的 network 子命令。
Docker 网络架构
Docker 在 1.9 版本中引入了一整套的 docker network 子命令和跨主机网络支持。这允许用户可以根据他们应用的拓扑架构创建虚拟网络并将容器接入其所对应的网络。其实，早在 docker 1.7 版本中，网络部分代码就已经被抽离并单独成为了 docker 的网络库，即 libnetwork。在此之后，容器的网络模式也被抽象变成了统一接口的驱动。
为了标准化网络驱动的开发步骤和支持多种网络驱动，docker 公司在 libnetwork 中使用了 CNM(Container Network Model)。CNM 定义了构建容器虚拟化网络的模型，同时还提供了可以用于开发多种网络驱动的标准化接口和组件。Libnetwork 和 docker daemon 及各个网络驱动的关系可以通过下图形象的表示：
上图中，docker daemon 通过调用 libnetwork 对外提供的 API 完成网络的创建和管理等功能。Libnetwork 内部则使用了 CNM 来实现网络功能。CNM 中主要有沙盒(sandbox)、端点(endpoint) 和网络(network) 3 种组件。Libnetwork 中内置的 5 种驱动则为 libnetwork 提供了不同类型的网络服务。下面分别对 CNM 中的 3 个核心组件和 libnetwork 中的 5 种内置驱动进行介绍。
CNM 中的 3 个核心组件如下
- 沙盒：一个沙盒包含了一个容器网络栈的信息。沙盒可以对容器的接口(interface)、路由和 DNS 设置等进行管理。沙盒的实现可以是 Linux network namespace、FreeBSD Jail 或者类似的机制。一个沙盒可以有多个端点和多个网络。
- 端点：一个端点可以加入一个沙盒和一个网络。端点的实现可以是 veth pair、Open vSwitch 内部端口或者相似的设备。一个端点可以属于一个网络并且只属于一个沙盒。
- 网络：一个网络是一组可以直接互相联通的端点。网络的实现可以是 Linux bridge、VLAN等。一个网络可以包含多个端点。
Libnetwork 中的 5 中内置驱动如下
bridge 驱动：这是 docker 设置的默认驱动。当使用 bridge 驱动时，libnetwork 将创建出来的 docker 容器连接到 docker0 网桥上。对于单机模式，bridge 驱动已经可以满足基本的需求了。但是这种模式下容器使用 NAT 方式与外界通信，这就增加了通信的复杂性。
host 驱动：使用 host 驱动的时候，libnetwork 不会为容器创建网络协议栈，即不会创建独立的 network namespace。Docker 容器中的进程处于宿主机的网络环境中，相当于容器和宿主机共用同一个 network namespace，容器共享使用宿主机的网卡、IP 和端口等资源。Host 模式很好的解决了容器与外界通信的地址转换问题，可以直接使用宿主机的 IP 进行通信，不存在虚拟化网络带来的开销。但是 host 驱动也降低了容器与容器之间、容器与宿主机之间网络的隔离性，引起网络资源的竞争和冲突。因此可以认为 host 驱动适用于对容器集群规模不大的场景。
overlay 驱动：overlay 驱动采用 IETF 标准的 VXLAN 方式，并且是 VXLAN 中被普遍认为最适合大规模的云计算虚拟化环境的 SDN controller 模式。在使用的过程中，还需要一个额外的配置存储服务，比如 Consul、etcd 或 ZooKeeper 等。并且在启动 docker daemon 的时候需要添加额外的参数来指定所使用的配置存储服务地址。
remote 驱动：这个驱动实际上并未做真正的网络服务实现，而是调用了用户自行实现的网络驱动插件，是 libnetwork 实现了驱动的插件化，更好地满足了用户的多样化需求。用户只要根据 libnetwork 提供的协议标准实现其接口并注册即可。
null 驱动：使用这种驱动的时候，docker 容器拥有字段的 network namespace，但是并不为 docker 容器进行任何网络配置。也就是说，这个容器除了 network namespace 自带的 loopback 网卡外，没有任何其它网卡、IP、路由等信息，需要用户为该容器添加网卡、配置 IP 等。这种模式如果不进行特定的配置是无法正常使用网络的，但是优点也非常明显，它给了用户最大的自由度来自定义容器的网络环境。
CNM 网络示例
这里我们介绍一个 libnetwork 示例的搭建过程，并在搭建成功后对其中容器之间的连通性进行验证。下图展示了 CNM 网络示例的组成结构：
在本例中，我使用 docker 默认的 bridge 驱动创建了一个网络拓扑应用：
- 它有两个网络，其中 backend network 为后端网络，frontend network 则为前端网络，两个网络互不连通。
- 其中 con1 和 con3 各拥有一个端点，并且分别加入到后端网络和前端网络中。而 con2 则有两个端点，它们分别加入到后端网络和前端网络中。
下面的命令分别创建名为 backend 和 frontend 的两个网络：
$ docker network create backend $ docker network create frontend $ docker network ls
上图中除了刚才创建的 backend 和 frontend 之外，还有三个网络 bridge、host 和 none。这三个网络是 docker daemon 默认创建的，我们无法通过 docker network rm 命令进行删除。
在创建了所需的两个网络之后，我们来创建三个容器 con1、con2 和 con3，并分别把 con1 和 con2 加入到 backend 网络中，把 con3 加入到 frontend 网络中：
$ docker run -it --name con1 --net backend busybox $ docker run -it --name con2 --net backend busybox $ docker run -it --name con3 --net frontend busybox
接下来分别在 con1 和 con3 中 ping con2，因为 con1 和 con2 都在 backend 网络中，所以两者可以连通。但是 con3 和 con2 不在一个网络中，所以它们之间不能连通。
我们查看 con2 中的网卡及其配置：
可以看到，此时容器中只有一块名为 eth0 的网卡，并且配置了和网桥 backend 同在一个 IP 段的 IP 地址，这个网卡就是 CNM 模型中的端点。然后我们通过下面的命令把 con2 也加入到 frontend 网络中：
$ docker network connect frontend con2
再来查看 con2 中的网卡及其配置：
这次发现多了一块名为 eth1 的网卡，并且其 IP 和网桥 frontend 同在一个 IP 段。用 ping 命令测试 con2 与 con3 的连通性：
此时两者已经连通。由此可知，docker network connect 命令会在所连接的容器中创建新的网卡，以完成容器与所指定网络的连接。
总结
通过 CNM(Container Network Model)，docker 为网络驱动的开发建立了标准。对于基本的网络应用场景，使用默认的网络驱动就能满足需求。如果用户有特殊的需求，完全可以依据 CNM 标准来实现自定义的网络驱动。
参考：
《docker 容器与容器云》
