理解Docker网络驱动和他们的用例

应用需求和网络环境是多样的，并且有时候针锋相对。在应用和网络之间有着Docker网络，亲切的叫做 Container 网络模型 或 CNM。CNM代理连接着Docker容器，而且在网络中常见的移除了多样性和复杂性。结果就是可移植性和来自CNM的强有力的网络驱动。这些为了Docker Engine、Swarm和UCP的扩展点接口提供特殊功能，像是多主机网络、网络层加密和服务发现。

自然，下一个问题就是我应该用哪个网络驱动？每个驱动试图权衡并且在根据用例不同有不同的优势。内置网络驱动包含在Docker Engine中，而且插件网络驱动也由网络供应商和社区提供。最常用的内置网络驱动是bridge, overlay 和macvlan。他们一起覆盖了非常广泛的网络用例列表和环境。为了更深入的比较和探讨更多的网络驱动，可以看看 Docker Network Reference Architecture.（https://success.docker.com/Datacenter/Apply/Docker_Reference_Architecture%3A_Designing_Scalable%2C_Portable_Docker_Container_Networks）

Bridge 网络驱动

bridge 网络驱动是的我们列表上的第一个驱动。它很容易理解、使用和故障检测，对开发者和刚使用Docker的人来说一个很好的网络选择。 bridge 驱动在主机内部创建一个私有网络，因此在这个网络中容器可以相互通讯。外部访问容器通过公开端口授权。Docker通过管理条约保护网络，阻止在不同的Docker网络之间连接。

在幕后，Docker Engine创建必要的Linux bridges、内部接口、防火墙规则和主机路由来实现连接。在下面高亮的例子当中，创建了一个Docker bridge网络，其中有2个容器。无需额外的配置，Docker Engine做了必要的装配，为容器提供服务发现功能，并且设置安全规则来阻止连接其他网络。内置IPAM驱动为容器接口提供私有IP地址，来自bridge网络的子网络。

在接下来的例子中，我们用一个虚构的、叫做 pets的app，它由一个web 和db 容器组成。在你自己的UCP或者Swarm集群上随意尝试一下。可以在 `:8000`上访问app。

docker network create -d bridge mybridge
 docker run -d --net mybridge --name db redis
 docker run -d --net mybridge -e DB=db -p 8000:5000 --name web chrch/web

应用现在在我们主机8000端口上可服务。Docker bridge允许 web用 db 通过它自己的容器名称来连接。bridge驱动自动的执行服务发现是因为它们在同样的网络。所有的端口映射、安全规则和管道工程在Linux bridges之间，是通过网络驱动来处理的，随着容器跨越一个集群来计划和调度。

bridge驱动是本地范围驱动，意味着它只能在一个主机上提供服务发现、IPAM和连接。多主机服务发现需要外部的解决方案，可以映射容器到它们的本地主机。这正是 overlay驱动为何如此棒了。

Overlay 网络驱动

内置Docker overlay网络驱动在多主机网络中彻底地简化了许多复杂性。它是swarm范围驱动，意味着它跨越整个Swarm或UCP集群操作而不是个别主机。通过 overlay驱动，在没有外部供应和组件的Docker内，多主机网络是一等公民。IPAM、服务发现、多主机链接、加密和负载平衡建立在其中。为了操控， overlay驱动在低点终止时间使用加密Swarm控制层来管理大规模集群。

overlay驱动利用VXLAN数据层行业标准，从下层的物理网络（底层）解耦容器网络。这样做的优势是跨越多种云和本地网络提供最大的可移植性。网络策略、可见性、和安全是通过Docker Universal Control Plane (UCP)来集中控制的。

在这个例子中我们在UCP中创建一个overlay网络，因此当我们在不同主机上时，我们可以连接 web和 db 容器。在一个overlay网络中，为了服务和容器的本地DNS服务发现将确 web可以解决 db ，反之亦然。打开加密，这样默认通讯在容器之间是安全的。此外，可见性和网络的运用在UCP中是受到限制的，通过权限标签。

UCP会计划服务跨越集群，而且UCP会动态的安排overlay网络提供连接到容器，无论他们在哪。当服务由多种容器支持，基于VIP的负载均衡将跨越所有容器分布流量。

用下面的CLI命令，随意运行这个例子防范UCP集群：

docker network create -d overlay --opt encrypted pets-overlay

docker service create --network pets-overlay --name db redis

docker service create --network pets-overlay -p 8000:5000 -e DB=db --name web chrch/web

在这个例子里，我们仍然在8000端口服务 webapp，但是现在我们跨越了不同主机部署应用。如果我们以前想缩放web容器、Swarm和UCP网络，将会自动负载均衡流量。

overlay 驱动是多功能的驱动，处理许多复杂性和集成，当制作零碎的解决方案时与组织斗争。它为许多网络挑战提供一个现成的解决方案，并在规模上如此。

MACVLAN 驱动

macvlan 驱动是一个最新的内置网络驱动，有一些独特的特征。它是一个轻量级的驱动，因为不是使用任何Linux 桥接或端口映射，它直接连接容器接口到主机接口。在外部的子网络上，用可路由IP地址解决容器。

由于可路由IP地址，容器和资源直接通讯，在一个Swarm集群外存在，没有使用NAT和端口映射。这可以帮助网络可视性和故障排除。此外，直接流量路径在容器之间，主机端口帮助减少潜在因素。 macvlan 是一个本地范围网络驱动，每个主机都要配置。因此，在MACVLAN和外部网络之间有严格的依赖性，这对两者既是约束也是优势，不同于overlay 和 bridge。

macvlan驱动使用父端口概念。这个端口可以作为一个主机端口，例如 eth0、一个界面或甚至一个结合主机适配器–捆绑以太网接口到一个单独本地接口中。在MACVLAN网络配置过程中，一个外部网络的网关地址是需要的，作为MACVLAN网络是从容器到网关的一个L2部分。像所有的Docker网络，MACVLAN网络是相互分割的——在网络中提供访问，但是不是在网络之间。

macvlan 驱动可以通过不同方法配置可以实现不同结果。在下面例子中，我们创建2个MACVLAN网络加入不同的子接口。这种配置风格可以用来延长多种L2 VLANs，通过主机接口直接到容器。默认VLAN网关存在外部网络。

在这个例子里， db和 web容器链接不同的MACVLAN网络。每个容器位于它各自的外部网络上，通过那个网络提供一个外部IP。使用这个设计，一个操作员可以在主机外控制网络策略和在L2上的部分容器。容器也可以安排在同样的VLAN中，通过把它们配置在同样的MACBLAN上。这只是显示了每个驱动提供的灵活性数量。

在Docker的理念中，可移植性和选择性是重要的用户。Docker容器网络模型为供应商提供一个开放端口和社区来创建网络驱动。Docker的互补发展和SDN技术每天正在提供更多的选项和功能。

工作愉快!

原文：Understanding Docker Networking Drivers And Their Use Cases
作者：Mark Church
来源：Docker
原文链接：https://blog.docker.com/2016/12/understanding-docker-networking-drivers-use-cases/

翻译：博云